[PATCH 00/11] Add labels support

[Stephen Finucane]

On Tue, 2018-08-21 at 14:43 -0400, Don Zickus wrote:
> On Tue, Aug 21, 2018 at 03:09:54PM +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.
> 
> Hi,
> 
> I missed the labels discussion patch, but at Red Hat we implemented
> something called 'tags' on our internal patchwork version which is probably
> the same idea.  It allows us to add arbitrary data like 'bugzilla' and
> 'needinfo' (and various CI tags) to our patches.  We have been trying to
> push parts of it to this mailing list
> 
> https://lists.ozlabs.org/pipermail/patchwork/2018-April/005098.html
> 
> with little success.  We would be interested in promoting either concept to
> patchwork.  Anything that allows us to attach random data to and is
> searchable/filterable.

Yeah, sorry about the delay reviewing that series. I've jumped on it
now and will do my best to push it to completion over the next few
weeks.

I see labels as different to tags. Tags are key:value pairs, generally
extracted from a message body, while Labels are simply values initially
stripped from the subject. We could build a unified model that supports
both, perhaps by making the value aspect of Tags nullable, but I'm not
sure if that's something we'd want nor how this would be handled in the
UI/APIs. What are your thoughts here?

Stephen

> Cheers,
> Don
> 
> >  
> > 
> > Would it simplify (or not?) the implementation if states became a
> > special case of labels?
> > 
> > cheers
> > _______________________________________________
> > Patchwork mailing list
> > Patchwork at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/patchwork