Patch tagging/classification

[Finucane, Stephen]

On 09 Feb 11:40, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 9 Feb 2016 10:35:12 +0000, Finucane, Stephen wrote:
> 
> > > Well, the tags are per-patch, so I don't really understand this
> > > question. Of course, you could make the tag support an optional
> > > functionality on a per-project basis, if that's what you mean.
> > 
> > So my concern is that some people tend to be careless when creating
> > things like tags. We probably want to avoid "tag hell", whereby there
> > are hundreds of tags with names like "TODO", "Todo", "todo", "todo2",
> > etc. I figure the only way to avoid this is to only allow certain
> > people to create tags, though anyone could theoretically assign them?
> 
> I understand your concern. And yes indeed, you could decide to allow
> only "maintainers" to create tags, but then let the patch authors
> themselves associate one or several of the existing tags to their
> patches.
>
> For example, in Bugzilla, only the bug tracker admin can create
> versions/milestones, but then every user reporting/managing bugs can
> tag a specific bug to apply to a given version or to be fixed in a
> given milestone.
> 
> Right now, in the Buildroot project, we are entering our "debug cycle".
> During this cycle, we don't merge any new features or package updates.
> But our patchwork is full of such patches. So it would be great to be
> able to tag patches to distinguish the ones that may potentially be
> considered for this release (bug fixes, minor improvements, security
> updates, etc.) from the ones that are definitely going to be for the
> next release.

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.
* 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?
* Labels can only be created by people with admin privileges, but can
  be assigned by anyone

What do you (or anyone else) think?

Stephen