TBH, a PR with more than 1400 changed files is hard to look at. How many of us will invest a few weeks at least to really understand it? We should assume that if we don't bring these changes piece by piece, we risk having an unstable version of SolrCloud for a while. When I look at some ongoing (unrelated) PR's judged too complex and being asked to split and simplify, this one would be at least two orders of magnitude "worse".
Maybe this means releasing 9 without this branch but with all recent changes so we have a relatively stable release and merging the branch into master right afterwards as the base for Solr 10, then accepting a relatively long "baking" and bug fixing period? A beta release of 10 might then make more sense, since it will be "release candidate" type code and not a separate branch that has diverged. Ilan Le mer. 7 oct. 2020 à 13:43, Jan Høydahl <[email protected]> a écrit : > We want/need these improvements, for sure! > Agree treating this whole thing as a black box is dangerous. At the same > time I realize that this will be one or a few huge merges anyway! > Rob’s suggestion is interesting! If at all possible to get the branch up > to date with master, and make a PR, then it’s a great way for all of us to > have a deeper look. > And, who knows, perhaps end of this month there is consensus for merging > into master sooner rather than later? > Especially if we have had reliably passing Jenkins runs of the new branch, > with all tests enabled, for some time! > Risk is of course that 9.0.0 could be an unusually unstable release, but > people don’t expect bug free x.0.0 releases. And to avoid cherry-pick hell > for 6-12 months, perhaps that’s not a bad option after all. > > Jan > > 7. okt. 2020 kl. 07:48 skrev Robert Muir <[email protected]>: > > > On Tue, Oct 6, 2020 at 10:45 PM Anshum Gupta <[email protected]> > wrote: > >> >> I haven’t looked at the current ref branch recently, but the folks who >> have looked at it, if you think that this code can be merged into master >> even as big chunks, that’d be the most confidence building way forward. >> >> > +1 for considering this approach. merge up master into the branch, and > make a big-ass PR to merge back. let people help review (maybe improve) the > change as a whole. It's just a big PR, some huge ones like this have been > done in lucene before too, unofficially called "unfuck" branches (sorry if > you are offended at my terminology). Sometimes you just fix, refactor, > cleanup, and keep iterating and see where it can lead. sometimes you revert > a bunch of commits because you followed the wrong rabbit-hole, etc. > Sometimes it may seem inconvenient, but I think we can all agree It's > important to have folks that want to not just take the small fix, but see > where it can go and make the whole thing better. Remember Mike's flexible > indexing branch? > > So why not try this way, look at actual code changes and try to get into > the master branch? Of course Uwe is willing to point build resources at it > either way, but if you want to maximize testing, start with the devs and > everyone's jenkins first before throwing at users. Master branch will get > you more testing, for sure. > > >
