maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Date Fri, 30 Dec 2016 08:01:58 GMT
On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <>  

> perhaps maven-resolver will require same reset


IMO we forgot to do a release with the original Aether code with the new  


> 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,
>> 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?
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message