Labels

[stephenfin]

From Mailing List

Overview

It should be possible to associate an arbitrary number of "labels" with any given patch in the web UI. These labels will function similarly to GitHub's Issue Labels or StackExchanges' Tags. This will allow filtering of patches destined for a specific release, priorities, etc. Some of these tags could be extracted from the subject, though we'd want to exclude versioning information (v2, V2) and series information (01/10) from this.

Dependencies

N/A

Additional Work Items

The addition of labels could allow for the the removal of some of the less useful default states, such as RFC, feeding into issue #4.

Labels could also be autogenerated by the rules that #18 would introduce.

Alternatives

Patch "categories" are another, more specific option. These would allow us to group patches by release, etc. but would not allow for things like labeling.

Useful Resources

• GitHub Issue Labels documentation
• StackExchange Tags overview

[ajdlinux]

Another potential use case - https://github.com/ruscur/snowpatch/issues/40

[stephenfin]

Based on that use-case, @ajdlinux, it sounds like we might want a user or verified field on a label (or rather, a SubmissionLabel through model). This would be populated with the User who set the Label on the Submission, if any. We could also set this field if an email comes from a specific User, though whether this is verifiable is not something I'm sure about.

[ajdlinux]

Yeah, that could work. Unfortunately email address isn't verifiable enough for our purposes, I suspect.

[rossburton]

My ticket (#566) got marked as a dup so I'll add my use-case here.

We have a single mailing list for patches for master and the release branches. Patches for master may be unmarked but patches for the release branch have their name in a label, eg "[PATCH][kirkstone] Fix frobnicate".

The problem comes when I want to use tooling to find merged patches by the patchwork hash, and if the same change has been sent for multiple release branches then I need to be able to filter by release label.

[rossburton]

Would https://github.com/jazzband/django-taggit be a relatively easy way to add arbitrary labels?

[rossburton]

I have literally no idea what I'm doing (the migrations need re-generating for a start) and it's barely usable, but https://github.com/rossburton/patchwork/tree/tags has a labels field in Submission managed by taggit, and if you manually add a tag then it appears in the submission template.

Obviously missing details:

• set labels when parsing the email
• ~filter (in/out) by label in the UI~
• Filter by label in the API. Specifically, when looking up a patch by hash, we should be able to control the labels.
• Maybe also a default label if none is set, so projects can use label as release series and default to master if not set otherwise.
• Buttons to set a label in the UI

[rossburton]

Against all expectations I guessed what the Filter class needs to do and it actually works, branch updated.

[stephenfin]

I've looked into this feature a few times. Each time, I've struggled to come up with a database schema that doesn't blow up our queries by causing a JOIN across entire tables.

I had a couple of thoughts about how this should work.

• I'd like the ability to create system/deployment-wide labels and project-specific labels. Things like RFC are broadly applicable, while things like stable-2.3 (a stable branch indicator) or component-foo would be specific to individual projects
• I think labels should be synonymous with tags in email subjects (e.g. [RFC][stable-2.3] A sample patch yields labels ['RFC', 'stable-2.3'] though it should be possible assign additional labels to a patch/series that were not present in the original mail.
• Labels should be able to be assigned to both series and patches. A label assigned to a series should cascade down to the patches.
• Crucially, we should avoid joins on large sets since those have been an issue previously.

I've yet to test out your patch, but how does this list align with your own set of expectations? fwiw, I'm more than happy to test and review this once it's suitably mature, though I can't really help with the development aspect of it right now.

[rossburton]

1) I'd be happy with per-project labels to be honest, it's not hard to add eg "RFC" to each project that wants to track labels. 2) Absolutely. Parsing those out is an important step. 3) Not done yet but I agree. 4) The taggit schema appears to be a table of tag slugs/names and then an intermediate table with indexes that maps, so lookups shouldn't be too explodey?

I'll carry on learning django and poking at this to see how it goes.

[stephenfin]

Sounds good to me. Let me know if you get seriously stuck and I can try help out, within the limits of available time.