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
