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

[Russell Currey]

On Tue, 2017-02-14 at 08:47 +1100, Daniel Axtens wrote:
> 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.

Even if *we* don't, it still seems like a good idea, i.e. for someone who is
only interested in patches for a specific category.  Having multiple projects on
the same list is dumb, but I've seen it enough times that it'd be good to
somewhat support.

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