[PATCH] REST: allow fetching of subject prefixes (categories)
andrew.donnellan at au1.ibm.com
Wed Feb 15 11:03:46 AEDT 2017
On 14/02/17 21:59, Stephen Finucane wrote:
>>> I'm not sure about 'categories' - this will also return things like
>>> version ('v2') and the number of the patch if it's in a series
>>> correct? Labels might be more valid, if so (though I had planned to
>>> 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.
> 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.
ACK, prefixes sounds good to me. (The labels concept looks great, can't
>>>> read_only_fields = ('project', 'msgid', 'date', 'name',
>>>> 'submitter', 'mbox', 'mbox',
>>>> - 'checks', 'tags')
>>>> + 'checks', 'tags', 'categories')
>>> Do we want to be able to filter on these? I don't know if you can
>>> 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
>> 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)?
Making life easier for clients usually is a win in and of itself :) But
additionally it's more semantically meaningful to expose this as a
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com IBM Australia Limited
More information about the Patchwork