I'm not against putting Jenkins config is source control: this will improve tracability. But until now, the PMC chair is supposed to be able to give karma [1]: this should be faster and IMHO remains useful.
If this does not work, an INFRA ticket should be opened Regards, Hervé [1] https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount Le jeudi 29 décembre 2016, 16:20:14 CET Stephen Connolly a écrit : > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
