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