[PATCH 00/11] Add labels support

[Daniel Axtens]

Stephen Finucane <stephen at that.guru> writes:

> On Tue, 2018-08-21 at 15:09 +1000, Michael Ellerman wrote:
>> 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?
>> 
>> Yes!
>> 
>> 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
>> workflow.
>> 
>> 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
>> though.
>> 
>> 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
>> differently.
>> 
>> 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?
>
> Oh, that's a really good idea, actually. The model I had been following
> for the "Remove State" series was to add two new fields to the "Patch"
> model: 'is_open' and 'resolution', the former being a boolean
> open/closed value and the later being an enum of the default state
> fields. I'd be happy to move this entire thing to labels though. Does
> anyone else (Daniel, Don) have thoughts on this?

I think that's the direction I'd like to go down - I think that will
allow people who want to consider 'rfc' to mean 'don't show me this'
will be able to, and you get all the benefits of labels that have been
listed. It seems like a win/win, and it's at least conceptually simpler.

So long as we can do it in a reasonably performant way, that is.

Regards,
Daniel

>
> Stephen