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

[Guilherme Salgado]

On Mon, 2011-04-04 at 18:00 -0300, Guilherme Salgado wrote:
> Hi there,
> 
> I've been working on a new patch-list page which includes all patches
> submitted by the logged in user (in fact by any Person linked to the
> logged in user) that are still waiting for feedback
> (state.action_required==True).  
> 
> The reason I've worked on this is because in Linaro we'd benefit from
> having a single place where users can see all their patches that haven't
> gotten feedback yet, without having to go to the patch-list of every
> project they might have contributed and filtering the patches there by
> submitter.  I think other users might find this useful as well, so here
> it is.
> 
> Notice that this is still a work in progress and, AFAIK, this is the
> first cross-project patch list, but it uses the same underlying
> infrastructure used by other patch lists, so some things there may not
> work (cross-project bundling, for instance). Also, the initial state of
> the filters does not reflect reality and this seems tricky to do as you
> can't use the UI to filter on multiple submitters, but I don't think
> this is that big a deal.

I've done some more testing and these are some things that will be
tricky to have working:

  - Restrict the values in the Delegate form field to the project   
    maintainers -- tricky as the patches are not from a single project

  - Bundle patches -- again, tricky as there are patches from multiple 
    projects and the DB schema doesn't permit that

  - At least the Submitter and State filters don't make much sense as 
    the purpose of the list is to show patches on a certain state 
    submitted by a certain user. I suppose this is similar to the 
    behavior of the State filter on the todo list?

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. 

-- 
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/20110405/a83577af/attachment.pgp>