[PATCH 00/11] Add labels support

[Don Zickus]

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.

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