On 15 Mar 22:04, Arnout Vandecappelle wrote: > >I'm waiting on reviews for cover letter feature, so I've picked this up > >as my next TODO item. I've something drafted and have made a couple of > >assumptions. Could you tell me if these would fit your needs? > > > >**NOTE:** I'm using the term 'labels' from now on, to prevent confusion > >with existing tag functionality (i.e. 'Reviewed-by'). > > > >* Labels are tied to a given project. If you have two or more projects > > on a given instance, they will need to create their own set of > > labels. Project_A and Project_B can both have the label 'XYZ', but > > these won't be related.
Actually, I stand corrected. Doing the above would require the 'Label' model having a many-to-many relationship with both a 'Project' and a 'Patch'. There doesn't seem to be any way to enforce this at the ORM level, and it would require an an external library like 'django-smart-selects' (or duplicating that library ourselves) for stuff like Django Admin. It seems all labels are going to have to be available across the entire instance. > >* Label names must be slugs, i.e. alphanumeric characters, underscores > > and hyphens only. > >* Labels will have an optional description, that will explain what said > > label signifies. > >* Labels will be implicitly disabled: if you don't create labels, then > > nothing will change from the user's perspective. However... > >* When enabled, labels will be displayed underneath each patch subject. > > This will mean you will have ~ half the patches per page, but I don't > > see how we can add another column without shedding other information? > > I don't expect dozens of labels on a single patch, and I expect the > labels to be relatively short. So in presentation, I would treat > them the same as [RFC], i.e. put in in square brackets in front of > the subject. Would all labels fit into this constraint? I'm thinking of labels like 'rc1-potential', which I'd commonly see used in an issue tracker. > In fact, it would be a nice additional feature if labels would be > assigned automatically when they are recognized like this from the > [PATCH] bit. In buildroot, for the 'next' branch that Thomas > described, people often send patches with subject prefix > [PATCH/next] or [PATCH next]. > > It would also be nice to add colour coding. Agree on both counts. How colorful though, if it's part of the subject line? Various shade of grey? Bold? Rainbow colors? Stephen _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
