Patch tagging/classification

[Thomas Petazzoni]

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.

> * 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.

> * 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.

> > 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 :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com