Am 12/29/16 um 16:04 schrieb Michael Osipov: > Am 2016-12-29 um 12:18 schrieb Stephen Connolly: >> 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? > > While I do agree to reset master on that commit and we do have deficits > here, there are some open questions: > > 1. Who and when is going to solve the CI problem? I personally do not > even have the permission on Jenkins to create a job to test my branch > stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve > flexibility. > > 2. Commit amount: >> $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l >> 328 > How do you want to replay non-breaking commits onto the new master? > Will you ask every committer to replay their commits? > > 3.4 is burned soil. Let's skip it. >
We should take this opportunity to also squash JIRA issues. There have been various JIRA tickes regarding the launcher scripts, for example. We should create a new JIRA issue superceding all of them and then squash all commits and make all of those commits for multiple JIRA issues just one commit on master for that one JIRA issue. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
