In the current osmo-msc.git split-up effort that will render openbsc.git to be legacy, there are a couple of very large commits on gerrit. In normal circumstances, my comment to these would be: "split this up!"
The way they came to be was: for a long time we were developing features on branches, with numerous separate small-sized commits. There were these problems with that:
Many commits partly or fully reverted earlier commits. It doesn't make sense to look at small and incomplete steps in wrong directions.
Rebasing this work onto recent developments became ludicrously cumbersome: solved merge conflicts were re-appearing with near every single following small commit, multiplying the effort for every little conflict resolution.
It was necessary to pull these commits together to fewer steps for conflict resolution, but some refactorings were done in-between other back-and-forth changes; combining patches by topics would also have been prohibitive effort.
The first step was thus to plain squash *all* into *one*. That is the current state of the libvlr changes (already merged), mscsplit changes (being merged now), IuCS (coming up) and AoIP+sigtran (coming up).
If it serves review, I am ready and willing to split these up into smaller bits, but if we can avoid spending time on that by reviewing the commits as whole, we can reduce time spent on cosmetics. The special nature of these patches is that they do pretty much completely overhaul the internal wiring and data structures: it makes sense to look at it as a whole and it's hard to pull out separate changes that are orthogonal.
So though this should not be the default style of our commits, this is a special situation. Do request a split up if you see a need. Otherwise we will merge them in these large code bombs as a basis for further dev.
Thanks!
~N
Hi Neels,
On Wed, Aug 16, 2017 at 01:46:17PM +0200, Neels Hofmeyr wrote:
If it serves review, I am ready and willing to split these up into smaller bits,
My Opinion: Please let's not drag this on for any longer and spend time on cosmetic issues like this. With architectural changes at code at this scale, I think there's only so much that review can resolve anyway. We need all forms of testing to help us iron out the kinks.
Our goal is to get the review and split-up done rather soon, so we and other can start testing, update packaging in OE, Debian, update manuals, wiki, etc.