[PATCH 00/11] Add labels support

[Michael Ellerman]

Don Zickus <dzickus at redhat.com> writes:

> On Tue, Sep 11, 2018 at 12:19:02PM -0600, Stephen Finucane wrote:
>> > > 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?
>
> Hi Stephen,
>
> Our internal workflow is a mixture.  We called everything 'tags' for
> consistency but really our data is either:
>
> *  key:value pairs extracted from message Body (bugzilla, acked-by, backported
>    commit id)
>
> *  arbitrary key:value pairs from automation tools (build id, test job id,
>    status of comment), nothing attributed to an email message body or easily
>    re-created by re-reading emails.
>
> Now I know you were not excited about arbitrary tags/labels when we first
> spoke, so we have been focusing on the first type of data.
>
> But ideally we would like both (or actually the second type covers the first
> type :-) ).  And I think the second type of data covers what Michael E. was
> describing for his needs (he called them labels).

Yeah I don't claim to have the terminology correct :)

But certainly "tags", ie. key/value string pairs, would work for me.

cheers