On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <run...@gmail.com> wrote: > >> On Apr 29, 2015, at 9:49 PM, Marcus <shadow...@gmail.com> wrote: >> >> After reviewing the history as mentioned by Daan, unless we propose >> and vote on a newer workflow model I think the best we can do is to >> simply be more strict about commits to master. They all need to be >> merges that have been tested against master before merge. This will in >> theory make master more stable, but doesn't really change the workflow >> we've already agreed upon and have been working under (although >> bugfixes sometimes were not coming in from branches, and cherry-picked >> bugfixes from branches will need to go into a branch first, tested >> against master, and merged to master). We can essentially set a date >> and do that any time, with some advance notice that direct commits >> will be reverted. > > Yes +1. > > -Set a date > -Tag master for reference > -Find a volunteer or two to RM master > -automatic revert on master if not from RM > -all commits to master come from PR, need clear review and green tests > -harden master (basic QA process), release 4.6 as a tag on master > -all features and fixes need to be made on branches or forks and onus is on > devs to rebase to master > -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4, etc) > -from there forward only maintain a linear release through master > > Feel free to add, tweak
I'm +0 on the above - what would push me to +1 would be stripping the RM as gatekeeper and letting CI be the gatekeeper (e.g. - all commits go in via PR that tests successfully.) I don't think that an RM is capable of understanding all of the pieces enough to judge any given patch, especially a more complicated patch, and its a SPOF - it's also incredibly difficult for a single person to keep up with all of the pending patches. I'd also be okay with must be reviewed by another committer so that two committers have to agree. Now, that said, if velocity is high, it will make kicking a release out somewhat difficult as the amount of churn is going to be high. > > PS: No need to vote if we have consensus. Taking a clue from ASF members, > votes should be avoided at all cost, they mean that we do not have clear > consensus. > > YES - this!!
