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

Guilherme Salgado guilherme.salgado at linaro.org
Mon Apr 11 23:08:15 EST 2011

On Thu, 2011-04-07 at 09:23 +0800, Jeremy Kerr wrote:
> 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.

Another thing I've just noticed we'll have to keep in mind is that in
these per-project lists, users won't be able to do mass-state-changes
unless they're the maintainers of the project in question.  We could
change generic_list() to behave differently and always include the
state-changing form, but this seems to me like yet another indication
that generic_list() may not be the appropriate thing to use here.

Guilherme Salgado <https://launchpad.net/~salgado>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20110411/76e06bb2/attachment.pgp>

More information about the Patchwork mailing list