Well Jenkins is my day job I have no issues seeking time to implement pipeline for Maven as that can be seen as benefiting the Jenkins OSS community as well as proving out pipeline for real world use cases.
Note the above is all pure OSS work not the for-pay side of my employers house. So I am expecting to be able to put some time into improving the CI usage of Maven If we go the multibranch route then basically once you create the branch in git you will get a branch specific job that build each commit until you remove the branch. No CI permission required. Most job configuration can be handled from the Jenkinsfile which is in git also. But the bigger questions we need to resolve first are the *what* questions... once we have those sorted the *how* questions will follow. Right now we need to get back releasing stuff or we are a dead project On Thu 29 Dec 2016 at 15:04, Michael Osipov <micha...@apache.org> wrote: > 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. > > > > Michael > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Sent from my phone
