With pipeline multibranch we should be able to get the integration test results as a GitHub status pushed back (perhaps even comments on JIRA)
Switching to pipeline multibranch should radically improve our CI infrastructure On Sat 31 Dec 2016 at 12:12, Tibor Digana <tibor.dig...@googlemail.com> wrote: > Stephen, > > > > Maybe we should add an icon (green/red) of build status on the page [1]. > > The same should appear on every pull request in GitHub Maven origin/master > > and branches. > > WDYT? > > [1] https://github.com/apache/maven-integration-testing > > > > T > > > > On Sat, Dec 31, 2016 at 1:07 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > On Saturday, 31 December 2016, Guillaume Boué <gb...@apache.org> wrote: > > > > > > > > > > > > > > > Le 30/12/2016 à 09:01, Robert Scholte a écrit : > > > > > > > >> 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? > > > >>>> > > > >>> > > > > Having a vote on all changes to master sounds too much. I think it > should > > > > be up to the developers to always raise discussions whenever a change > > > would > > > > have impacts on existing ITs, or whenever a new feature is considered > to > > > be > > > > added. Bug fixing should be able to be pushed easily; only a commit > > > message > > > > describing what the bug actually is, and how the fix is done should be > > > > necessary. > > > > > > > > > I don't think we are suggesting that. > > > > > > I think we are probably looking at worst case switching the integration > > > tests repo from CTR to RTC > > > > > > Though personally I think that is a bit too much. I think adding new > tests > > > can be CTR but any changes to existing tests probably need to be RTC or > at > > > least have a separate discussion first. Changes to the integration test > > > suite can erode confidence which is one of the reasons for considering > the > > > "big reset" > > > > > > For Maven core repo, the real issue here is that there was a charge ahead > > > fixing bugs without having the previously agreed "stability" release > which > > > just included the change from aether to resolver > > > > > > > > > > > > > > Commits should, as much as possible, represent a whole unit. That is, > if > > > > it wouldn't make sense to revert to a given revision (because it > > > represents > > > > some temporary dev state, or incomplete state), then probably that > > > revision > > > > shouldn't exist. Tests ran on Jenkins should be a last-resort (or close > > > to > > > > it) IMO: any change that is commited should be tested as passing, > > > possibly > > > > on different OS (if the change looks like OS dependent) and different > > > Maven > > > > versions for plugins (I personally test with 3.0.5, 3.3.9 and latest > > > > snapshot so that a wide range of versions are covered). > > > > > > > > > +1 > > > > > > If committers need licenses for windows then we can direct them to the > MSDN > > > licensing which Microsoft provides to Apache committers (or is it just > > > members?) or there are those 30-day VMs that MS provides for IE > > > compatibility testing which could also be used for MS compatibility > testing > > > > > > > > > > > > > > > > > >>>> 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? > > > >>>> > > > >>> > > > > What exactly would this scenario imply? > > > > > > > > > > Reset back to just after 3.3.9 and then merge *only* the changes for > the > > > "drop-in" replacement of aether by resolver. Nothing else. > > > > > > After we get 3.5.0 out then we start cherry picking those things that we > > > agree should be released from the 3.4.x branch > > > > > > > > > > If it is skipping 3.4.x and releasing current codebase as 3.5.0, I'm > not > > > > sure it changes anything. I'd favor picking the commits between the > > > > proposed hash and today, releasing that as 3.4.0 and defering > contentious > > > > changes. As far as the picking goes, having a mail thread for each JIRA > > > > issue doesn't sound practical but may be needed... > > > > > > > > > We probably just need to do a bug scrub and decide what should be fixed > > > > > > In fact perhaps we should try and have regular bug scrubs to schedule > what > > > should be on the roadmap > > > > > > > > > > > > > > I have a question regarding the possible new commits. Will Git retain > the > > > > actual author / date / comment of the initial commits when doing the > > > cherry > > > > picking? I believe that info should really be kept, but I'm not sure if > > > it > > > > possible (or wanted). > > > > > > > > > It is *the most important thing at the Apache Foundation* that the > > > *authorship* of a commit is retained. > > > > > > Cherry picking retains authorship but may modify the committer. This is > > > fine and normal. Generally the original committer should be driving the > > > cherry-picks > > > > > > > > > > > > > >>>> 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 > > > >> > > > >> > > > > > > > > --- > > > > L'absence de virus dans ce courrier électronique a été vérifiée par le > > > > logiciel antivirus Avast. > > > > https://www.avast.com/antivirus > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > -- > > > Sent from my phone > > > > > > > > > > > -- > > Cheers > > Tibor > > -- Sent from my phone
