[PATCH] REST: allow fetching of subject prefixes (categories)

[Daniel Axtens]

Hi Stephen,

> On Sat, 2017-02-11 at 21:55 +1100, Daniel Axtens wrote:
>> Some mailing lists accept patches for multiple projects, and use
>> a subject prefix to differentiate the projects.
>
> A couple of comments on this starting with this one: should we not be
> considering patches like this as belonging to a different 'Project' in
> Patchwork? If we don't do already support something, maybe we should?
>
> Could you provide an example of a mailing list that does this?

Yes - OpenBMC does this. The one mailing list supports the OpenBMC
project, and within that they deal with code for several different
components - the kernel, u-boot, etc:

https://patchwork.ozlabs.org/project/openbmc/list/?state=*

They (generally!) use these subject prefixes to distinguish between
patches for different components/projects.

>> +    def get_categories(self, instance):
>> +        return clean_subject(instance.name)[1]
>
> This is going to run for 'page_size' patches on the list operation. I
> don't know how expensive each run is but seeing as there are regexes
> involved I doubt it's free. I wonder if we should access this via a
> 'cached_property' field on 'Submission'?

That's a good idea. I'll spin a v2 with that.

>
>>      def get_mbox(self, instance):
>>          request = self.context.get('request')
>> @@ -100,10 +105,10 @@ class
>> PatchListSerializer(HyperlinkedModelSerializer):
>>          fields = ('id', 'url', 'project', 'msgid', 'date', 'name',
>>                    'commit_ref', 'pull_url', 'state', 'archived',
>> 'hash',
>>                    'submitter', 'delegate', 'mbox', 'series',
>> 'check', 'checks',
>> -                  'tags')
>> +                  'tags', 'categories')
>
> I'm not sure about 'categories' - this will also return things like the
> version ('v2') and the number of the patch if it's in a series ('1/5'),
> correct? Labels might be more valid, if so (though I had planned to use
> that name for a more significant feature in v2.1 or so [1]).

That's valid. I'm happy to leave 'labels' if you have designs on that
for future. How about 'prefixes'? That also works well for leaving in
version and series markers - they're all prefixes.

>
>>          read_only_fields = ('project', 'msgid', 'date', 'name',
>> 'hash',
>>                              'submitter', 'mbox', 'mbox', 'series',
>> 'check',
>> -                            'checks', 'tags')
>> +                            'checks', 'tags', 'categories')
>
> Do we want to be able to filter on these? I don't know if you can do
> this for non-model fields though...

At the moment, no. The use case is our CI system where we want to be
able to take each patch one by one and figure out which tree to apply it
to. So we don't need to filter on categories/prefixes.

Regards,
Daniel

> Stephen
>
> [1] https://github.com/getpatchwork/patchwork/issues/22