On Wed, Sep 12, 2018, 07:41 Jim Jagielski <j...@jagunet.com> wrote: > Ahh. I think I see the problem! For some reason Bill sees this as somehow > Jim's (my) fork. It's not. It's a svn branch from HEAD of trunk, which > contains > all the changes. That branch is the projects's branch not some personal > fork, whatever that means. >
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 Now, why would we *need* a 2.5.x branch? The only thing I can picture is someone proposes post-2.6 work. And for the time being, such work can and should live in a sandbox, imo. Again, sorry I missed the transition from discussing trunk to discussing 2.4.x branch. I completely support your initial suggestion of the basis, modulo tagging these pre-2.6.0 candidates directly on trunk.
