> On Oct 29, 2019, at 9:36 AM, Eric Covener <cove...@gmail.com> wrote: > > On Tue, Oct 29, 2019 at 9:18 AM Luca Toscano <toscano.l...@gmail.com > <mailto:toscano.l...@gmail.com>> wrote: >> >> Hi everybody, >> >> Il giorno ven 25 ott 2019 alle ore 12:52 Yann Ylavic >> <ylavic....@gmail.com> ha scritto: >>> >>> 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 >> >> The above proposal from Yann seems to be something that could work for >> everybody as far as I can tell, what do you think? Do we need an >> explicit vote thread? > > Nit: Not using 2.5.x is a departure from convention. > > I don't think a wholesale vote is needed for #1-5. I am skeptical > there is interest/velocity in getting past #2. > By the time we're at #8, I would say a vote is warranted as an > additional branch has a cost.
My only question regards workflow w/ trunk. Right now, I think we all agree that there are codepaths and features in trunk that are not as stable as we would like. Which is fine... trunk is CTR. But we do need some way to vet those changes (ie, we need to "R" all those "C"s). Some will be accepted, others not. Into what branch do those accepted go? And for the things not accepted for eventually inclusion in 2.5/2.6, do they get removed from trunk? Do they stay in trunk? So it seems to me that we need to branch trunk into 2.5.x and "clean up" that branch (items 1-5) and leave trunk alone. Just my 2c
