[PATCH 00/11] Add labels support

Michael Ellerman mpe at ellerman.id.au
Tue Aug 21 15:09:54 AEST 2018

Andrew Donnellan <andrew.donnellan at au1.ibm.com> writes:

> On 09/08/18 18:54, Daniel Axtens wrote:
>>> This series starts work on the latter of these by addressing yet another
>>> issues, #22 [3]. Full details of the feature are provided inline but
>>> tl;dr labels are arbitrary bits of metadata that can be used to
>>> represent some of the more orthogonal states like "RFC" or "Under
>>> Review" along with other maintainer-provided labels. Once we have
>>> support for this, we can build upon it to migrate some of the 'states'
>>> to labels and the 'state' field itself to a boolean field. This is all
>>> in the future though.
>> So I haven't read through the patches in great detail, but I want to
>> just query the idea that RFC is orthogonal. I understand a bunch of
>> maintainers have a general policy of not merging RFC patches, so if
>> something is posted as RFC they just mark it as RFC on Patchwork and
>> then don't ever look at it again.
> + mpe: I think we touched on this issue of the orthogonality of the RFC 
> classification when we were chatting about snowpatch things the other day?


I think this gets to the heart of the problem with states vs labels,
which is that RFC can be either, depending on the maintainer's preferred

Because RFC is currently a state it is typical to just mark RFC patches
as RFC and then ignore them. That's not great feedback for the submitter

It would be nicer if the patch was tagged as RFC but could then still
have its state marked as "under review", then "changes requested" or
straight to "accepted" if it's in a state to be merged.

By being marked as RFC it could be excluded by a maintainer from the
list of "patches people are expecting me to merge".

But that's just an example, other maintainers might want to handle them

Personally I would *really* like labels to land. They unlock a lot of
potential improvements to workflow for maintainers, eg. automated
tagging, tagging based on test results etc. As well as finer grained
reporting of status to submitters, eg. instead of "new" -> "under
review" -> "accepted", I can mark a patch as "under review" and
"applied-to-some-branch", then "under review" and
"in-testing" etc. etc.

Would it simplify (or not?) the implementation if states became a
special case of labels?


More information about the Patchwork mailing list