Patch tagging/classification

Finucane, Stephen stephen.finucane at
Mon Feb 8 23:21:34 AEDT 2016

On 07 Feb 16:02, Thomas Petazzoni wrote:
> Hello,
> I don't remember if I already suggested this feature, or if it has been
> suggested in the past already. If that's the case, then sorry for the
> duplicate.
> Over at the Buildroot project, we often handle a fairly long queue of
> patches in our patchwork, currently around 350+ patches. One thing that
> I'm missing is a way of triaging/tagging the patches, like which ones
> are for the current release, which ones are clearly for the next
> release, etc. Each project probably has different
> tagging/classification needs.
> Wouldn't it be useful to create a tagging system which allows to
> associate an arbitrary list of tags to each patch. This could even
> replace the delegation feature by adding special tags like
> "delegate:<account>" to delegate the patch to a certain user. This
> would also have the benefit of allowing the delegation to more than one
> user, by simply having several "delegate:<account>" tags on the same
> patch.
> This of course should come with filters in the web UI, in order to
> filter patches depending on the tags that they have.
> Thoughts?

I like it: it reminds me a little bit of both StackExchange's "tags"
system [1] or GitHub's "labels" [2] and should provide a good boost in
making patchwork a little more "indexable". I think we should decide
which aspects of the above approaches we should take (I'm using the tag
nomenclature for now).

* Who should be able to create tags: project admins, maintainers, or
* Should the tags be tied to the specific patchwork project or the
  entire instance? AFAIK the current "tag" implementation (for
  Acked-by, Reviewed-by tags) is instance-wide, though disableable
  on a per-project basis.
* Is there any value in parsing non-versioning subject prefixes as
  tags, e.g. extracting 'project' from '[PATCH project]'? This could
  be a later enhancement.
* Should we be case-sensitive, allow spaces etc.?

I'm not too sure about replacing the delegate feature, however. While I
do see the overlap, I think delegating a patch is a different operation
from assigning a tag. For example: a user will likely wish to see
patches delegated to them on their homepage.

> Side question: has the patchwork project considered participating to
> the Google Summer of Code? I believe patchwork is really a good project
> for GSoC students: it's using a technology that is worth learning,
> getting into the internals of patchwork is not too complicated, etc.

I considered it, but I couldn't think of anything meaty enough that
people weren't already working on. Perhaps this would be a good start?


> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> _______________________________________________
> Patchwork mailing list
> Patchwork at

More information about the Patchwork mailing list