Don Zickus <dzic...@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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
