[PATCH 00/11] Add labels support

[Don Zickus]

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


We are ok with ACLs for setting them (as long as our bots can get
permission).

Does that make sense?

Cheers,
Don