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
