OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.4.x and 2.6.x ... next steps



> On Sep 12, 2018, at 9:39 AM, William A Rowe Jr <wrowe@xxxxxxxxxxxxx> wrote:
> 
> 
> So although others mentioned 2.4.x branch, this is not the origin of YOUR proposal. Wow, that simplifies this discussion a lot (and hopefully, our new committers who never even corresponded with some long absent colleagues now see my concern with the dismissiveness against using trunk.) Sorry that I misattributed that part of the discussion to your proposal.
> 
> Here is the problem I have with forking today. I expect you know I have no problem with tagging 2.5.1-alpha any day of the week and putting 2.5 candidates up for release vote.
> 
> During the 'development' of 2.odd we have no need to fork, because all API/ABI changes are permitted between 2.5.1 and 2.5.2. Our trunk needs to be usable all the time, not just during this release prep. But, forking introduces a mess of svn maintenance to no justified purpose.
> 
> And most of all, we need to trust our fellow committers. It is clear that review before or after does not eliminate all errors. But 2.5 will not be GA (2.6 will be.)
> 
> The straight line, avoiding a ton of excess backports, and keeping it simple on the RM, is to either 1. Tag from the final, accepted 2.5.x svn commit rev into 2.6.x branch, or 2. from trunk to 2.6.x branch if the RM believes the changes are limited risk, and can be vetted during the release vote.
> 
> Forking 2.5.x says, outright, I don't trust my fellow committers with commit bits to the alpha/beta development branch. That is also a bad signal to send 

Not at all. It sez "here is a safe space to continue to go wild and here is a place where there is an expected direct path to a releasable version"... no diff from when we had httpd-2.2, httpd-2.4 and trunk. We just have httpd-2.4, httpd-2.5 and trunk.

And again, ALL of this is predicated on the assumption that there is stuff in trunk (really useful and tested stuff) that cannot be backported to 2.4. Obviously, it is a lot easier, and takes a lot less time, to continue as we are and backport as we can; even some of the "impossible" stuff may actually be backportable with less effort than spinning 2.5/2.6. And, again personally, I think we are doing an extremely good job in balancing things between trunk and httpd-2.4, with most divergences either fluff or sandbox-type refactorings that may not pass muster when all is said and done.