[RFC] A new page listing the user's patches that are waiting for feedback

Jeremy Kerr jk at ozlabs.org
Thu Apr 7 11:23:59 EST 2011

Hi Guilherme,

> Given the above, I'm kind of leaning towards not using the existing
> generic_list() helper and omitting the filters, the form to bundle
> patches and the Delegate field from the Properties form. This would make
> sure we don't mislead users into doing things that won't actually work
> as they expect, but it also leaves the ability to change the state
> and/or archive patches, which I think is quite useful.

I've wanted to add a 'my patches' view previously, so thanks for taking
a look at this. However, the multiple-projects-on-one-list part does
make this a bit difficult.

Would separating the patches by project still work for you?

I'd imagined implementing this by:

      * Adding a "my patches for $project" view, which should just be a
        matter of configuring the filters correctly. Other than the
        submitter filter, the other filters would have the usual default
        settings, and be changeable via the UI. This means that we get
        the "action required" patches by default, but the user can still
        get the full list easily.

      * Changing the 'contributor to...' text at the top of the
        userprofile view to something (a table?) listing the numbers of
        patches in an action required state. Project names would be
        links to the "my patches for $project". This gives a quick
        overview of patches in all projects.

The downside of this is that if a user is participating in multiple
projects, they need to visit multiple pages if they want to see the list
of all patches. However, I think this is okay, for a few reasons:

      * Although users may be contributing to multiple projects, it's
        likely that only one or two would be their main focus of
        attention at any one time.

      * Cross-posting a patch to multiple (patchwork-enabled) projects
        would results in multiple entries on the 'my patches' page, only
        one being relevant. Cross-posting a series of patches will make
        this unusable, unless we can then filter by project.

      * With the current patchwork installations, the projects on each
        server (patchwork.ozlabs.org/patchwork.kernel.org/others) may
        not have any specific grouping; this puts the 'my patches' into
        fairly arbitrary groups.

Any thoughts?


More information about the Patchwork mailing list