Stephen Finucane <[email protected]> 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 _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
