maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
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 <herve.boutemy@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?
>>
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message