[PATCH] REST: allow fetching of subject prefixes (categories)
ruscur at russell.cc
Tue Feb 14 09:54:10 AEDT 2017
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:
> They (generally!) use these subject prefixes to distinguish between
> patches for different components/projects.
> > > + def get_categories(self, instance):
> > > + return clean_subject(instance.name)
> > 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 ).
> 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
> > Stephen
> >  https://github.com/getpatchwork/patchwork/issues/22
More information about the Patchwork