[PATCH v2 2/6] models: Add 'Event' model

[Daniel Axtens]

Stephen Finucane <stephen at that.guru> writes:

> On Tue, 2017-02-07 at 08:11 +1100, Daniel Axtens wrote:
>> Hi Stephen,
>> 
>> I'm reviewing this series as I get time,
>
> FYI - there's another version of this series coming in the next day or
> two that will add some more events. I'll try to account for these
> changes in the commit messages but the generic foreign keys are gone.

Cool. I haven't read that yet, so don't stress too much about messing
with my head :P


>>  but one general question -
>> should any of this be hidden behind a config option? I'm wondering if
>> anyone who doesn't want REST or is nervous about the performance
>> impact
>> might want to turn it off (or at least might want to be able to turn
>> it
>> off).
>> 
>> Thoughts?
>
> We /could/, but it would remove a really valuable feature that I plan
> to make a lot of use of. This feature is pretty vital for CI systems,
> which need a way to quickly identify when patches have been received,
> had their dependencies met etc. I also want to expose this lifecycle
> information in the UI in a similar pattern to Launchpad, GitHub etc. I
> can't imagine this affecting performance in any serious way, given that
> it will only be triggered on certain lifecycle events. However, I'm
> open to benchmarking this if I can find out how :)

I agree it's really useful; I just worry about kernel.org which receives
a stupid amount of email each day and (as I understand it) is pretty
cagey about adding new features...

Anyway, I'll work on benchmarking; then we can at least test we don't
regress. I think we want to cover mail parsing and UI/API
interaction. Mail parsing is pretty easy to test, interaction less
so. I'll let you know how I go.

Regards,
Daniel

>
>> (Relatedly, I guess a patchwork benchmark might not be a bad idea -
>> make
>> sure we don't regress catastrophically without noticing...)
>
> Not a bad idea. I wonder how we'd do this?
>
> Stephen