On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > As I said in the past, my idea would be to: > - trunk -> trunk-old, > - copy 2.4.x -> trunk > - any feature to bring from trunk-old to the new trunk needs a champion, e.g. > someone who does the work (porting and test cases)
I'm not sure, possibly it would be easier to remove/restore from/to trunk than backport to 2.6.x. I think most things are in pretty good shape in trunk, core things at least. If we were to merge the missing/interesting bits in a 2.6.x-copy-of-2.4.x, it could be a mess to find all the commits in trunk for each feature. (Say something /me did, as you very well know it's very likely to be spread over multiple commits and back and forth in time :) ) > > To some, that looks like we do not honour past work from people (that was one > of the arguments brought forward last time). If, due to the above difficulty for finding all the relevant bits to backport, it ends up being large replacement of code (nay whole files) with no real merge, I think that's a point though. Basing 2.6.x off trunk would preserve history on the things we want to keep and maintain, and possibly would be easier to start with (let's discuss that!), so best of both worlds? > But it is not only about honour of devs, but also about the sweat and tears > of the maintainers during 2.6.x releases. If a feature does not find someone > to merge from one branch to another, how could we support this feature in a > release? Agreed. > What do the 5-6 people who handle 99% of all PRs think about this? My feeling is that it's easier to start from trunk, no strong feeling (an intuitive one). So how about: 0. github workflow? meanwhile... 1. compare trunk/2.4.x (inventory) 2. discuss unused/deprecated in trunk to cleanup 3. address STALLED entries in trunk if it's not for compatibily reasons 4. do API/ABI breaking changes in trunk 5. improve trunk w/ things we want in 2.6.x (the real part!) 6. trunk => 2.6.x 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either 8. 2.6.alpha/beta/gamma/rc/whatever 9. fix in trunk and backport to 2.6.x 10. if not good enough goto 8. 11. 2.6.0 12+ usual release cycle ? If in 1. we find that 2.4.x => 2.6.x is easier/better, well just replace 2. with that and drop 6. and 7.
