Repository navigation
Labels #22
Description
Activity
Another potential use case - ruscur/snowpatch#40
Based on that use-case, @ajdlinux, it sounds like we might want a
userorverifiedfield on a label (or rather, aSubmissionLabelthrough model). This would be populated with theUserwho set theLabelon theSubmission, if any. We could also set this field if an email comes from a specificUser, though whether this is verifiable is not something I'm sure about.Reacted by Andrew Donnellan and Russell CurreyYeah, that could work. Unfortunately email address isn't verifiable enough for our purposes, I suspect.
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.
Would https://github.com/jazzband/django-taggit be a relatively easy way to add arbitrary labels?
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
labelsfield 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
Against all expectations I guessed what the Filter class needs to do and it actually works, branch updated.
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
JOINacross 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
RFCare broadly applicable, while things likestable-2.3(a stable branch indicator) orcomponent-foowould be specific to individual projects - I think labels should be synonymous with tags in email subjects (e.g.
[RFC][stable-2.3] A sample patchyields 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.
- I'd like the ability to create system/deployment-wide labels and project-specific labels. Things like
- 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.
- Absolutely. Parsing those out is an important step.
- Not done yet but I agree.
- 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.
Sounds good to me. Let me know if you get seriously stuck and I can try help out, within the limits of available time.
Hello,
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 found your patch implementing labels from 2018, with many-to-many relation between Patch and Tag tables. django-taggit library seems to use a similar approach.
Are the extra joins unacceptable also for filtering by labels? Do you have any numbers on how bad the performance problem was?I thought about the problem for a bit and I'm wondering if any of the following solutions were considered or would be acceptable:
- Caching the labels as a string in Patch table. That way the tags table is joined only when someone filters by tags.
- Storing tags as an array in Patch table and creating a GIN index on that. This article series claims good performance with that approach. Unfortunately, this is not supported by MySQL at all.
I also thought about storing tags as a string in Patch table and having a fulltext index on that. This would be compatible both with MySQL and Postgres, but I'm not yet convinced that stopwords and stemming won't get in the way.
FWIW, I started looking at using taggit some time ago (whilst also learning django). What I did is at https://github.com/rossburton/patchwork/commits/tags/, but it's incomplete, old, and probably terrible. :)
@stephenfin
Maybe I'm getting too ahead of myself with indexing, I don't see any mentions of full text indexes in code or migrations, yet text search seems to work ok. Database created by patchwork only contains btree indexes.
Maybe just having a space delimited string with labels as a field, and querying patches with something along the lines ofWHERE labels_field LIKE '% queried_label %'would be good enough? No joins required (the label->color table will have to be queried manually from the backend, but it should be pretty small).Although to be fair my dev patchwork instance became pretty slow after importing a couple thousand patches. I'm wondering if "production" patchwork instances use any extra out-of-tree database optimizations.
FWIW, I started looking at using taggit some time ago (whilst also learning django). What I did is at https://github.com/rossburton/patchwork/commits/tags/, but it's incomplete, old, and probably terrible. :)
@rossburton Thanks, this may become useful later.
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