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

[Stephen Finucane]

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.

Lovely! :)

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

Prefixes sounds good to me. Given that labels will probably function
quite similarly [*], it's likely that they'll completely replace this
in a future version of Patchwork and it would be best to avoid any
confusion over the two.

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

Yeah, I'm not too bothered about this unless it's easy to do.

I do have one final question: this information is already available in
the 'name' field, right? What extra functionality would this give us
other than slight simplification of the client side code (though maybe
that's enough of a win by itself)?

Cheers,
Stephen

[*] The last time we discussed labels on the mailing list, it was
suggested that we display labels inline in the subject by simply adding
them to the list of existing prefixes. As such, labels ~= custom
prefixes.