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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
