Patch tagging/classification

Finucane, Stephen stephen.finucane at intel.com
Tue Feb 9 21:35:12 AEDT 2016


On 09 Feb 10:05, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 8 Feb 2016 12:21:34 +0000, Finucane, Stephen wrote:
> 
> > 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
> >   everyone?
> 
> Probably the maintainers and the author of the patch ?
> 
> > * 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.
> 
> 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?
 
> > * 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.
> 
> Could be, though for the purpose of the Buildroot project, that
> probably wouldn't be that useful. Or maybe some really explicit tags in
> the patch itself, like Patchwork-tags: foo bar baz.

Spotted this after in the bug Damien linked. I guess we can add it in
the future if needs must.

> > * Should we be case-sensitive, allow spaces etc.?
> 
> To me, space should be the separator between tags. Case-sensitive, I
> don't really care, but everything in Unix is case-sensitive, so
> probably it should be as well.
>
> > 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.
> 
> Hmm? Th code showing the patches delegated to someone on its homepage
> can be changed to some logic that lists all patches having
> "delegate:<account>" as a tag. Again, it allows delegating to multiple
> persons, which the current implementation doesn't allow.

This is true. Hmm - let me think about it :)

> > > 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?
> 
> Yes, this could be a project. But ideally you need several ideas to
> propose to GSoC candidates, and then also candidate as an organization.
> You have until February 19 for this, so hurry up :-)

Eek! I'll start fishing for ideas today.

Cheers,
Stephen


More information about the Patchwork mailing list