Feature request: delegating patches to others than maintainers

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Tue Jul 21 18:45:48 AEST 2015


On Tue, 21 Jul 2015 08:17:56 +0000, Finucane, Stephen wrote:

> > Yes. In my "profile", it says:
> > 
> >   Contributor to buildroot, crosstool-ng, devicetree-bindings,
> >   linux-gpio, linux-i2c, linux-ide, linux-imx, linux-mtd, linux-pci,
> >   linuxppc-dev, netdev, netfilter-devel, patchwork, rtc-linux,
> >   sparclinux, uboot.
> > 
> > So apparently patchwork is able to know to which project I posted at
> > least one patch. So maybe you can show only the users that have
> > contributed at least one patch in the project?
> > 
> > Or simply we need a new flag for users, like "maintainers" but that
> > doesn't give them the right to manipulate all patches, only the ones
> > that have been delegated to them.
> This means that, post-change, you could delegate to either a
> maintainer or a prior contributor who happened to have a patchwork
> account but not anyone else. Would this be acceptable? (I don't think
> it'd be necessary to take this approach, but just making sure in
> case).

Yes, for the first proposal (which doesn't require a flag). Generally,
people to whom you would want to delegate patches have already
contributed at least one patch to the project. Otherwise they wouldn't
have your trust to get a patch delegated to them. But maybe this is an
assumption that is valid for some projects but not all.

> Finally, would the non-maintainers be able to set state to any state.
> In Gerrit, the submitter of a patch can abandon or rebase the patch,
> but can't merge it unless they're a maintainer/core dev. We don't
> have to worry about rebasing or merging, but setting the status to
> Accepted is basically the same thing, right? Can we assume the
> assigned delegate won't update with any misleading information? :)

Depends which level of control you want. Since maintainers are in
charge of delegating ton non-maintainers, you could assume they would
delegate to trusted persons so that having those persons change the
state to any state would not be a problem. But I can understand that
some projects may want a tighter control on that.

However, patchwork's beauty is its simplicity. If it becomes too
complicated with myriad of config options, it would lose a bit of its

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the Patchwork mailing list