On 14/02/17 21:59, Stephen Finucane wrote:
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.
ACK, prefixes sounds good to me. (The labels concept looks great, can't
wait!)
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)?
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
separate field.
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
