[PATCH 00/11] Add labels support

[Stephen Finucane]

On Wed, 2018-09-12 at 15:59 -0400, Don Zickus wrote:
> 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)

Yeah, this what I envision tags being for. These are mostly human
written or at least human readable and would be something you'd want to
count.

> *  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.

This sounds like checks [1]. I know that these wouldn't exactly map to
what you have currently, but would these be suitable solution? If not,
what gaps do you see that would need to be closed?

> 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).
> 
> We are ok with ACLs for setting them (as long as our bots can get
> permission).

For what it's worth, there's an ACL of sorts in place for checks: you
need to have a Patchwork account and the username of the user that
creates the check is stored and displayed in both the UI and API. I'm
hoping to extend this to add permissions so only certain anointed users
(read: bots) can create checks but I just haven't gotten around to that
yet.

> Does that make sense?
> 
> Cheers,
> Don

Cheers,
Stephen

[1] https://patchwork.readthedocs.io/en/latest/usage/overview/#checks