[PATCH 00/11] Add labels support
mpe at ellerman.id.au
Tue Sep 25 13:30:10 AEST 2018
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
>> 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.
More information about the Patchwork