I'm not seeing any objections to the general idea. On Tuesday I'll post a draft of the vote proposal to this thread... then if everyone is happy (translation: nobody says "I'm not happy") I'll start the vote on Wednesday 3rd... usual 72h but I'll probably wait for Monday 9th Jan before closing (unless we have evidence of a lack of consensus after 72h)
Assuming the vote is successfully, I'll raise the INFRA tickets and we can hopefully have an RC a couple of days later. WDYT? - Stephen On Thu 29 Dec 2016 at 11:18, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On ASF infra, our master branch is supposed to be a protected branch and > thus cannot be reset or force-pushed without an INFRA ticket. > > If we want to reset our master branch in order to clean out the history of > the many changes and reverts to and fro etc, we thus need an INFRA ticket > raised. > > INFRA should not act on such a ticket without the results of a vote of the > committers that has at least three binding votes from the PMC (i.e. the > majority of votes cast must be in favour and at least three PMC members > must have voted in favour) > > Votes are a great way to *confirm* consensus, but a horrible way to build > a community or establish consensus. We should only ever have a vote thread > once the consensus seems to be established. > > To establish consensus we use a discuss thread. > > Please refrain from assigning blame, we want to grow our community not > shrink it. The shorty endorphin rush you get from assigning blame or > performing The Dance Of I Told You So™ will require repeated hits to > maintain which will only lead to a more toxic community. > > We have not been good at maintaining our CI infrastructure: > > * As a consequence, some people have been developing on master rather than > on branches in order to ensure that their development gets the benefit of > the integration tests > > * This has lead to a lot of micro commits and effectively revert commits > on master making it hard to track what actually has changed and what has > actually been fixed. > > * Additionally `git blame` probably now could end up confusing people > trying to understand the rationale for some changes > > We have not been good at maintaining our Integration tests: > > * As a consequence it has been hard to get our CI infrastructure working > effectively > > * As a consequence, people have been forced to leverage a single branch > for CI testing > > We have not been good at developing bigger changes in a branch > > etc. > > I could go on. > > My belief is that confidence in 3.4.0 has been eroded. > > I propose that we reset master back > to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of > master for the integration tests, and then immediately commit a dummy > commit so that nobody accidentally does a fast-forward push. > > Then we can cherry pick the changes that were on the old master that we > want to have in 3.4.0 > > This will probably also involve: > > * Fixing the CI infrastructure (I favour using a pipeline multibranch > project so that branch development is easier, > https://builds.apache.org/job/maven-jenkinsfile/ is where I have been > trying to prototype this... currently failing because "windows") > > * Switching to a culture of branch / PR development for all committers > > * Better providing rationale for changes, e.g. we need a succinct > description of the actual regression between 2.x and 3.x in resolution of > dependencies of plugins as well as actual easy to understand tests that > demonstrate the behaviour *and* show that it is an actual regression > > * etc > > But the first step in that would be to reset master... > > So... > > Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset to? > > What is the correct hash for the integration tests? > > Do we want to do this? > > What else should we change about our processes to prevent the need to do > this again? > > Should we maybe just drop 3.4.x and jump to 3.5.x also in order to signal > that this was a reboot version and any 3.4.x stuff is thus easy to detect > and filter? > > Save your +1/-1's for actual vote threads, we need to establish a > consensus first... then in a couple of days, if it looks like we have a > consensus I will call a vote. > > -Stephen > -- Sent from my phone
