On Thu, 19 Nov 2015, Christian Franke wrote:
Yes, imho, we absolutely do need to optimize for latency. While we
probably won't see patches as large as those recently submitted from
Cumulus every other week, it is a burden if patches that cause merge
conflicts with pending devolepments are pending for long time. These
conflicts are not necessarily an insurmountable issue, but I'd rather
spend time on coding that performing git acrobatics.
Yeah, agreed, the constant rebasing and merging is a pain.
I'm not sure that's inherently to do with latency though. It's to do with
the serialisation of work into one tree, and it's a function of the number
of distributed/non-serialised changes and their overlap. Serialising with
lower or higher latency need not affect the amount of conflicts (ignoring
second order effects).
E.g. once patches are serialised into a 'proposed' queue, does it make a
difference if they wait there 3 days or 2 weeks?
The other aspect it to better manage and minimise the
serialisation/conflict issues and de-tangle, modularise and separate
things as and when we can.
The more modular the code, the fewer conflicts we should have, hopefully,
and the easier the serialisation becomes, and the faster integration can
go - without demanding much more of the patch herders and reviewers (it
may need more work by submitters though).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Not everything worth doing is worth doing well.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
