What hash do we want to reset resolved to? (We will be *renaming* master in all cases so that the history is available... just not on master)
On Fri 30 Dec 2016 at 08:02, Robert Scholte <rfscho...@apache.org> wrote: > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > > > > perhaps maven-resolver will require same reset > > > > +1 > > > > IMO we forgot to do a release with the original Aether code with the new > > GAVs. > > > > Robert > > > > > > > > and we'll need to define which convention to use on Jira when merging > > > code: > > > remove "Fix Version: 3.4.0" for example, to track what features have not > > > been > > > merged yet > > > > > > Regards, > > > > > > Hervé > > > > > > Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit : > > >> 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 > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Sent from my phone
