[PATCH 3/4] parser: allow to handle multiple projects under the same list

[Philippe Pepiot]

On 05/30/2017 09:54 PM, Stephen Finucane wrote:
> On Tue, 2017-05-30 at 10:37 -0700, Sean Farley wrote:
>> Andrew Donnellan <andrew.donnellan at au1.ibm.com> writes:
>>
>>> On 30/05/17 08:50, Stephen Finucane wrote:
>>>> On Sat, 2017-05-27 at 20:17 +0200, Philippe Pepiot wrote:
>>>>> By adding a `subject_prefix` settings to Project. Mail will be
>>>>> assigned to project if List-Id match and prefix is present.
>>>>>
>>>>> Signed-off-by: Philippe Pepiot <phil at philpep.org>
>>>>
>>>> Hmm, so I'm not entirely sure about this. On one hand, I
>>>> understand why it would be helpful to do this. However, commit
>>>> '66a88a46' was supposed to address this. Is there something that
>>>> that change doesn't have that you need to expose? I've CCd the
>>>> authors/reviewers of that change to get their input.
>>>>
>>>> fwiw, in the longer term I'd like to add a label feature that
>>>> would track most of the labels found in subjects (i.e. everything
>>>> except 'PATCH', 'RFC', 'nn/mm' and 'vNN' tags). This is decidedly
>>>> a 2.1+ goal, however.
>>>
>>> 66a88a46 was designed purely to solve the issue of figuring out
>>> which repository to apply a patch to for CI purposes, nothing more.
>>>
>>> I can see why a maintainer may want to go all the way and consider
>>> it to be a full separate patchwork project, but I don't think the
>>> maintainers of any of the lists I'm on that use subject prefixes
>>> would want to do this.
>>>
>>> You're also going to have to deal with the inevitable patch that
>>> misses the correct prefix (a particular trap for new contributors).
>>>
>>> I'm not opposed to adding this if there are maintainers who have
>>> reasons why they would like to have completely separate projects,
>>> though from a CI perspective I think we're adequately served
>>> already.
>>
>> The Mercurial project currently uses this prefix-as-a-different-
>> project template. It'd be a nice to have, for sure (setting up
>> different perms and rules, for example), but maybe just having
>> different labels is enough. I'd be +0 on it.
> 
> I hadn't considered the value of separate projects outside of different
> links; having the ability to set different permissions and rules, as
> you suggest, would be quite nifty.
> 
> If this is something that would be used by more than one user, then I'd
> personally be OK with letting it in. *However*, as Andrew suggests
> above, we still need to think about how to move patches between
> projects when sent without the correct prefix. This, coupled with the
> fact we're already on the third 2.0 release candidate, suggests this is
> in firm 2.1 territory :) If you need this right now, I'm pretty sure
> you could modify 'parsemail' to do this filtering locally and set up
> your separate projects.
> 
> Thanks for the input, folks,
> Stephen

My concern wasn't to have different rules or maintainers, but just
easily list patches that belong to a specific repository. We currently
have > 10 different repositories behind a single list (a "framework",
without prefix, and multiple "extensions" with dedicated prefix).

I see two paths to handle this, either having different projects or
having a better support for subject prefixes. Currently, in REST API,
prefixes are only available on patch detail view and are computed by
parsing the subject, we may want materialize them in database and allow
to filter them in patch list view.

On the other side, having different project and set patch project on
multiple criteria (list-id + prefix, or maybe a X-Patchwork-Project
header ?) seems simpler and open more features (different maintainers,
rules and future features related to a project).

Agree that we need a way (UI + REST) to update patch project before.
If nobody strongly disagree, I may improve this series for next 2.1

Cheers,