You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2016/12/29 11:18:59 UTC
[DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
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
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Hervé BOUTEMY <he...@free.fr>.
I'm not against putting Jenkins config is source control: this will improve
tracability.
But until now, the PMC chair is supposed to be able to give karma [1]: this
should be faster and IMHO remains useful.
If this does not work, an INFRA ticket should be opened
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount
Le jeudi 29 décembre 2016, 16:20:14 CET Stephen Connolly a écrit :
> Well Jenkins is my day job
>
> I have no issues seeking time to implement pipeline for Maven as that can
> be seen as benefiting the Jenkins OSS community as well as proving out
> pipeline for real world use cases.
>
> Note the above is all pure OSS work not the for-pay side of my employers
> house.
>
> So I am expecting to be able to put some time into improving the CI usage
> of Maven
>
> If we go the multibranch route then basically once you create the branch in
> git you will get a branch specific job that build each commit until you
> remove the branch. No CI permission required. Most job configuration can be
> handled from the Jenkinsfile which is in git also.
>
> But the bigger questions we need to resolve first are the *what*
> questions... once we have those sorted the *how* questions will follow.
> Right now we need to get back releasing stuff or we are a dead project
>
> On Thu 29 Dec 2016 at 15:04, Michael Osipov <mi...@apache.org> wrote:
> > Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
> > > 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?
> >
> > While I do agree to reset master on that commit and we do have deficits
> >
> > here, there are some open questions:
> >
> >
> >
> > 1. Who and when is going to solve the CI problem? I personally do not
> >
> > even have the permission on Jenkins to create a job to test my branch
> >
> > stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
> >
> > flexibility.
> >
> > 2. Commit amount:
> > > $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc
> >
> > -l
> >
> > > 328
> >
> > How do you want to replay non-breaking commits onto the new master?
> >
> > Will you ask every committer to replay their commits?
> >
> >
> >
> > 3.4 is burned soil. Let's skip it.
> >
> >
> >
> > Michael
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > --
>
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
Well Jenkins is my day job
I have no issues seeking time to implement pipeline for Maven as that can
be seen as benefiting the Jenkins OSS community as well as proving out
pipeline for real world use cases.
Note the above is all pure OSS work not the for-pay side of my employers
house.
So I am expecting to be able to put some time into improving the CI usage
of Maven
If we go the multibranch route then basically once you create the branch in
git you will get a branch specific job that build each commit until you
remove the branch. No CI permission required. Most job configuration can be
handled from the Jenkinsfile which is in git also.
But the bigger questions we need to resolve first are the *what*
questions... once we have those sorted the *how* questions will follow.
Right now we need to get back releasing stuff or we are a dead project
On Thu 29 Dec 2016 at 15:04, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
>
> > 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?
>
>
>
> While I do agree to reset master on that commit and we do have deficits
>
> here, there are some open questions:
>
>
>
> 1. Who and when is going to solve the CI problem? I personally do not
>
> even have the permission on Jenkins to create a job to test my branch
>
> stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
>
> flexibility.
>
>
>
> 2. Commit amount:
>
> > $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc
> -l
>
> > 328
>
> How do you want to replay non-breaking commits onto the new master?
>
> Will you ask every committer to replay their commits?
>
>
>
> 3.4 is burned soil. Let's skip it.
>
>
>
> Michael
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-29 um 20:41 schrieb Christian Schulte:
> Am 12/29/16 um 16:04 schrieb Michael Osipov:
>> Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
>>> 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?
>>
>> While I do agree to reset master on that commit and we do have deficits
>> here, there are some open questions:
>>
>> 1. Who and when is going to solve the CI problem? I personally do not
>> even have the permission on Jenkins to create a job to test my branch
>> stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
>> flexibility.
>>
>> 2. Commit amount:
>>> $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
>>> 328
>> How do you want to replay non-breaking commits onto the new master?
>> Will you ask every committer to replay their commits?
>>
>> 3.4 is burned soil. Let's skip it.
>>
>
> We should take this opportunity to also squash JIRA issues. There have
> been various JIRA tickes regarding the launcher scripts, for example. We
> should create a new JIRA issue superceding all of them and then squash
> all commits and make all of those commits for multiple JIRA issues just
> one commit on master for that one JIRA issue.
I wouldn't do that. It would kill traceability for the reporter. If one
ticket required two or more commits, this should be squashed or course.
I'd like to keep changes to working commits as little as possible.
Especially because one needs to change all change comments on JIRA due
to new hashes.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/29/16 um 16:04 schrieb Michael Osipov:
> Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
>> 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\u2122 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?
>
> While I do agree to reset master on that commit and we do have deficits
> here, there are some open questions:
>
> 1. Who and when is going to solve the CI problem? I personally do not
> even have the permission on Jenkins to create a job to test my branch
> stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
> flexibility.
>
> 2. Commit amount:
>> $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
>> 328
> How do you want to replay non-breaking commits onto the new master?
> Will you ask every committer to replay their commits?
>
> 3.4 is burned soil. Let's skip it.
>
We should take this opportunity to also squash JIRA issues. There have
been various JIRA tickes regarding the launcher scripts, for example. We
should create a new JIRA issue superceding all of them and then squash
all commits and make all of those commits for multiple JIRA issues just
one commit on master for that one JIRA issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-29 um 12:18 schrieb Stephen Connolly:
> 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?
While I do agree to reset master on that commit and we do have deficits
here, there are some open questions:
1. Who and when is going to solve the CI problem? I personally do not
even have the permission on Jenkins to create a job to test my branch
stuff. See the big discussion about Wagon 2.11 and Jetty 8. Devs deserve
flexibility.
2. Commit amount:
> $ git log --oneline 737de43e392fc15a0ce366db98d70aa18b3f6c03..HEAD | wc -l
> 328
How do you want to replay non-breaking commits onto the new master?
Will you ask every committer to replay their commits?
3.4 is burned soil. Let's skip it.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/29/16 um 18:57 schrieb Herv� BOUTEMY:
> perhaps maven-resolver will require same reset
No need for this. Reverting MRESOLVER-8 and MRESOLVER-9 will be
sufficient. Those are one-line style of commits. The rest of the commits
do not change any behaviour.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Hervé BOUTEMY <he...@free.fr>.
good question.
Here are some options:
1. last release used in Maven 3.3.9, ie Aether 1.0.2.v20150114
sha1 8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e [1], that is currently
HEAD of 1.0.x branch
2. code imported to Apache, that I tagged as aether-core-import in master
sha1 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b [2], 1.1.0-SNAPSHOT
Notice that I don't precisely know what is different from 1.0.2.v20150114
3. the last commit before changes that go beyond gav partial updates (because
changes were done before import vote was finished)
sha1 11a061b66fd15b8c3584f48afa69955d9392861e [3]
The biggest question is: what is the precise impact of 1.0.2 vs 1.1.0-
SNAPSHOT?
I personnally don't know
Regards,
Hervé
[1] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
8092eaecbd34bd7bf18f49cb8a99bd218fb6e30e
[2]
https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
[3]
https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
11a061b66fd15b8c3584f48afa69955d9392861e
Le vendredi 30 décembre 2016, 13:54:58 CET Stephen Connolly a écrit :
> What hash do we want to reset resolved to?
>
> (We will be *renaming* master in all cases so that the history is
> available... just not on master)
>
> On Fri 30 Dec 2016 at 08:02, Robert Scholte <rf...@apache.org> wrote:
> > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <he...@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
> >
> >
> >
> > --
>
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
I thought you had said that it was a regression introduced in 3.0, so if
prerequisites is 2.x then you should resolve the "fixed" way as that was
the way of 2.x that you are *restoring*
The only reason for the bug reproduction on [3.0,3.4) is because people
developing against the 3.x versions might have used hacks to work around
the "bug" and hence need protection so that their "hacks" still work
On Sun 1 Jan 2017 at 07:11, Christian Schulte <cs...@schulte.it> wrote:
> Am 01/01/17 um 08:06 schrieb Christian Schulte:
>
> > Am 01/01/17 um 07:52 schrieb Christian Schulte:
>
> >> is uncovering bugs in the poms. Current master is passing all core ITs,
>
> >> all plugin ITs and also can be used to build all plugins, if you
>
> >> manually change to a different plugin tools release
>
> >> (-DmavenPluginToolsVersion=3.3 or 3.5).
>
> >
>
> > It's not even needed to change the plugin tools version any more. Only
>
> > plugins having declared
>
> >
>
> > <prerequisites>3.4</prerequisites>
>
> >
>
> > would get the correct resolution.
>
>
>
> And all of our plugins already are working with that correct resolution
>
> in place but are still resolved the old way, because they declare
>
> prerequisites 2.0, 2.2.1 or 3.0. You can declare them prerequsisite 3.4
>
> today and they'll work.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 08:06 schrieb Christian Schulte:
> Am 01/01/17 um 07:52 schrieb Christian Schulte:
>> is uncovering bugs in the poms. Current master is passing all core ITs,
>> all plugin ITs and also can be used to build all plugins, if you
>> manually change to a different plugin tools release
>> (-DmavenPluginToolsVersion=3.3 or 3.5).
>
> It's not even needed to change the plugin tools version any more. Only
> plugins having declared
>
> <prerequisites>3.4</prerequisites>
>
> would get the correct resolution.
And all of our plugins already are working with that correct resolution
in place but are still resolved the old way, because they declare
prerequisites 2.0, 2.2.1 or 3.0. You can declare them prerequsisite 3.4
today and they'll work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 08:06 schrieb Christian Schulte:
> It's not even needed to change the plugin tools version any more. Only
> plugins having declared
>
> <prerequisites>3.4</prerequisites>
>
> would get the correct resolution.
As of yesterday.
Happy new year everyone, BTW.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 07:52 schrieb Christian Schulte:
> is uncovering bugs in the poms. Current master is passing all core ITs,
> all plugin ITs and also can be used to build all plugins, if you
> manually change to a different plugin tools release
> (-DmavenPluginToolsVersion=3.3 or 3.5).
It's not even needed to change the plugin tools version any more. Only
plugins having declared
<prerequisites>3.4</prerequisites>
would get the correct resolution. Everyhing else is resolved the way no
one knew about. There cannot be any plugin out there which has this in
the pom. You would not even notice things have changed as long as you do
not put such a prerequisite into the pom.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Tibor Digana <ti...@googlemail.com>.
Hi Stephen. In the Roadmap you have mentioned that all the discussion of
particular Jira issue is discussed in ML.
I cannot imaging how the code would be discussed here. Why not in pull
request at github?
In the repository with ASF rights INFRA can create labels like you have
proposed "?" or "+1" or milestone "3.5" etc.
https://help.github.com/articles/creating-and-editing-labels-for-issues-and-pull-requests/
On Tue, Jan 3, 2017 at 6:52 PM, Manfred Moser <ma...@simpligility.com>
wrote:
> I am +100 on that. Thanks for taking the initiative to get things back on
> track.
>
> Manfred
>
> Stephen Connolly wrote on 2017-01-03 09:40:
>
> > I believe we have consensus, here is the final call for anyone objecting
> to
> > the plan to have their opinions considered.
> >
> > Here is the draft of the proposal for the vote:
> >
> > NOTE: THIS IS *NOT* THE VOTE
> >
> > -----BEGIN DRAFT-----
> > Hi,
> >
> > We have collectively managed to mess up our ability to follow the
> original
> > release plan for 3.4.0 which was originally supposed to consist of an
> > effective no-op change of Eclipse's Aether for the code after migration
> to
> > Apache's Maven Resolver plus some other orthogonal changes around logging
> > colourization and launcher script bug fixes.
> >
> > Given that some developer private builds of the current master branch
> have
> > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
> > closed with a fixed version of 3.4.0.
> >
> > For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
> > with our user community.
> >
> > Additionally the informal practice of keeping existing integration tests
> as
> > RTC has not been followed, leading to some people to question whether the
> > integration tests remain valid.
> >
> > For all the above reasons it is proposed to do *all* the following as an
> > whole:
> >
> > 1. In git://git.apache.org/maven.git we will rename the current master
> > branch to `pre-reset-master` and recreate `master` as (TODO HASH
> > corresponding to a commit that does a version bump to 3.5.0-SNAPSHOT on
> top
> > of 737de43e392fc15a0ce366db98d70aa18b3f6c03 - by having a commit that is
> > not on the current master branch it will prevent accidental fast-forward
> > commits)
> >
> > 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the
> > current master branch to `pre-reset-master` and recreate `master` as
> (TODO
> > HASH corresponding to a commit on top of 94bd771c88cc96014ca0ddaa07ac6f
> > 778b3c7501)
> >
> > 3. In git://git.apache.org/maven-resolver.git we will rename the current
> > master branch to `pre-reset-master` and recreate `master`
> > as b74f7a1e8837875b4780199f644119f55d22465d (i.e. the 1.0.x branch)
> >
> > We will then proceed to have (ideally) the original committers
> cherry-pick
> > (and tidy up an squash... if the original committers are not able to
> assist
> > then squashing may not be practicable) those changes that have been
> agreed
> > for 3.5.0 as summarized on the
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> > (authorative source of the decisions summarized in the wiki page is the
> > mail thread:
> > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
> > ).
> >
> > As this involves a --force push on the `master` branch, we want to get
> the
> > approval of the committers before continuing.
> >
> > The vote will be open for at least 72 hours.
> >
> > The vote will be decided by a simple majority of valid votes cast. There
> is
> > no veto.
> >
> > The vote is open to all committers.
> >
> > In addition, for the vote to be valid, there must be at least 3x+1 votes
> > from PMC members
> >
> > TODO: insert voting options template
> >
> > -Stephen
> > -----END DRAFT-----
> >
> > I'm going to start the vote in a clean thread some time tomorrow. Any
> > suggested changes will need to be provided before say 12:00 UTC,
> >
> > If you do not agree that we have consensus (i.e. you are likely to vote
> -1)
> > please stand up and let us know your concerns so that we may adapt the
> plan
> > to include your concerns. There is no harm in not liking the current
> plan,
> > we would rather delay and alter our plan to address your concerns and
> have
> > the vote thread as a formality rather than the vote thread becoming a
> > source of conflict and disharmony in our community.
> >
> > Before I call the vote I will push the forking changes to maven and
> > maven-integration-testing onto a separate branch so that the vote thread
> > can include those hashes. I am delaying doing that until tomorrow in case
> > there is a change in plan on which hash to base off.
> >
> > Fun times!
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Cheers
Tibor
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Manfred Moser <ma...@simpligility.com>.
I am +100 on that. Thanks for taking the initiative to get things back on track.
Manfred
Stephen Connolly wrote on 2017-01-03 09:40:
> I believe we have consensus, here is the final call for anyone objecting to
> the plan to have their opinions considered.
>
> Here is the draft of the proposal for the vote:
>
> NOTE: THIS IS *NOT* THE VOTE
>
> -----BEGIN DRAFT-----
> Hi,
>
> We have collectively managed to mess up our ability to follow the original
> release plan for 3.4.0 which was originally supposed to consist of an
> effective no-op change of Eclipse's Aether for the code after migration to
> Apache's Maven Resolver plus some other orthogonal changes around logging
> colourization and launcher script bug fixes.
>
> Given that some developer private builds of the current master branch have
> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
> closed with a fixed version of 3.4.0.
>
> For us to release a 3.4.0 with those fixes reverted, could cause confusion
> with our user community.
>
> Additionally the informal practice of keeping existing integration tests as
> RTC has not been followed, leading to some people to question whether the
> integration tests remain valid.
>
> For all the above reasons it is proposed to do *all* the following as an
> whole:
>
> 1. In git://git.apache.org/maven.git we will rename the current master
> branch to `pre-reset-master` and recreate `master` as (TODO HASH
> corresponding to a commit that does a version bump to 3.5.0-SNAPSHOT on top
> of 737de43e392fc15a0ce366db98d70aa18b3f6c03 - by having a commit that is
> not on the current master branch it will prevent accidental fast-forward
> commits)
>
> 2. In git://git.apache.org/maven-integration-testing.git we will rename the
> current master branch to `pre-reset-master` and recreate `master` as (TODO
> HASH corresponding to a commit on top of 94bd771c88cc96014ca0ddaa07ac6f
> 778b3c7501)
>
> 3. In git://git.apache.org/maven-resolver.git we will rename the current
> master branch to `pre-reset-master` and recreate `master`
> as b74f7a1e8837875b4780199f644119f55d22465d (i.e. the 1.0.x branch)
>
> We will then proceed to have (ideally) the original committers cherry-pick
> (and tidy up an squash... if the original committers are not able to assist
> then squashing may not be practicable) those changes that have been agreed
> for 3.5.0 as summarized on the
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> (authorative source of the decisions summarized in the wiki page is the
> mail thread:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
> ).
>
> As this involves a --force push on the `master` branch, we want to get the
> approval of the committers before continuing.
>
> The vote will be open for at least 72 hours.
>
> The vote will be decided by a simple majority of valid votes cast. There is
> no veto.
>
> The vote is open to all committers.
>
> In addition, for the vote to be valid, there must be at least 3x+1 votes
> from PMC members
>
> TODO: insert voting options template
>
> -Stephen
> -----END DRAFT-----
>
> I'm going to start the vote in a clean thread some time tomorrow. Any
> suggested changes will need to be provided before say 12:00 UTC,
>
> If you do not agree that we have consensus (i.e. you are likely to vote -1)
> please stand up and let us know your concerns so that we may adapt the plan
> to include your concerns. There is no harm in not liking the current plan,
> we would rather delay and alter our plan to address your concerns and have
> the vote thread as a formality rather than the vote thread becoming a
> source of conflict and disharmony in our community.
>
> Before I call the vote I will push the forking changes to maven and
> maven-integration-testing onto a separate branch so that the vote thread
> can include those hashes. I am delaying doing that until tomorrow in case
> there is a change in plan on which hash to base off.
>
> Fun times!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
I believe we have consensus, here is the final call for anyone objecting to
the plan to have their opinions considered.
Here is the draft of the proposal for the vote:
NOTE: THIS IS *NOT* THE VOTE
-----BEGIN DRAFT-----
Hi,
We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apache's Maven Resolver plus some other orthogonal changes around logging
colourization and launcher script bug fixes.
Given that some developer private builds of the current master branch have
been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
closed with a fixed version of 3.4.0.
For us to release a 3.4.0 with those fixes reverted, could cause confusion
with our user community.
Additionally the informal practice of keeping existing integration tests as
RTC has not been followed, leading to some people to question whether the
integration tests remain valid.
For all the above reasons it is proposed to do *all* the following as an
whole:
1. In git://git.apache.org/maven.git we will rename the current master
branch to `pre-reset-master` and recreate `master` as (TODO HASH
corresponding to a commit that does a version bump to 3.5.0-SNAPSHOT on top
of 737de43e392fc15a0ce366db98d70aa18b3f6c03 - by having a commit that is
not on the current master branch it will prevent accidental fast-forward
commits)
2. In git://git.apache.org/maven-integration-testing.git we will rename the
current master branch to `pre-reset-master` and recreate `master` as (TODO
HASH corresponding to a commit on top of 94bd771c88cc96014ca0ddaa07ac6f
778b3c7501)
3. In git://git.apache.org/maven-resolver.git we will rename the current
master branch to `pre-reset-master` and recreate `master`
as b74f7a1e8837875b4780199f644119f55d22465d (i.e. the 1.0.x branch)
We will then proceed to have (ideally) the original committers cherry-pick
(and tidy up an squash... if the original committers are not able to assist
then squashing may not be practicable) those changes that have been agreed
for 3.5.0 as summarized on the
https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
(authorative source of the decisions summarized in the wiki page is the
mail thread:
https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
).
As this involves a --force push on the `master` branch, we want to get the
approval of the committers before continuing.
The vote will be open for at least 72 hours.
The vote will be decided by a simple majority of valid votes cast. There is
no veto.
The vote is open to all committers.
In addition, for the vote to be valid, there must be at least 3x+1 votes
from PMC members
TODO: insert voting options template
-Stephen
-----END DRAFT-----
I'm going to start the vote in a clean thread some time tomorrow. Any
suggested changes will need to be provided before say 12:00 UTC,
If you do not agree that we have consensus (i.e. you are likely to vote -1)
please stand up and let us know your concerns so that we may adapt the plan
to include your concerns. There is no harm in not liking the current plan,
we would rather delay and alter our plan to address your concerns and have
the vote thread as a formality rather than the vote thread becoming a
source of conflict and disharmony in our community.
Before I call the vote I will push the forking changes to maven and
maven-integration-testing onto a separate branch so that the vote thread
can include those hashes. I am delaying doing that until tomorrow in case
there is a change in plan on which hash to base off.
Fun times!
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
We need to get a release that is *the same as 3.3.9 only with aether
swapped for resolver* first IMHO.
That was the original plan...
Then people started wanting to add bug fixes and lots of other stuff.
The point of a reset is to return to the original plan.
Bugs orthogonal to the aether->resolver change could be included... but
there is a risk we go a step too far
What we want to be able to say is: if you currently use 3.3.9 you can
upgrade with zero risk to 3.5.0
Then we start fixing bugs in 3.5.1, etc... but we have moved our *head*
users onto the 3.5.x line and can start bringing the others with us
On Sun 1 Jan 2017 at 08:04, Christian Schulte <cs...@schulte.it> wrote:
> Am 01/01/17 um 08:23 schrieb Christian Schulte:
>
> > Am 01/01/17 um 08:18 schrieb Christian Schulte:
>
> >> Once more I asked someone to test a snapshot and provided a link to
>
> >> Jenkins. That's where all those commits come from. I hope I'll get
>
> >> feedback on this one and that could again lead to commits. Doing this on
>
> >> a release branch - yes - I got that.
>
> >
>
> > And you do want someone grabbing that snapshot to get all changes done
>
> > by all committers and not just some build of some personal branch which
>
> > is lacking all other development. Let master be the release branch but
>
> > let there be a branch all development of all committers is taking place.
>
>
>
> Reverting things just to keep them the way they were instead of
>
> clarifying things and finding better solutions is the worst thing you
>
> can do, IMO.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 08:23 schrieb Christian Schulte:
> Am 01/01/17 um 08:18 schrieb Christian Schulte:
>> Once more I asked someone to test a snapshot and provided a link to
>> Jenkins. That's where all those commits come from. I hope I'll get
>> feedback on this one and that could again lead to commits. Doing this on
>> a release branch - yes - I got that.
>
> And you do want someone grabbing that snapshot to get all changes done
> by all committers and not just some build of some personal branch which
> is lacking all other development. Let master be the release branch but
> let there be a branch all development of all committers is taking place.
Reverting things just to keep them the way they were instead of
clarifying things and finding better solutions is the worst thing you
can do, IMO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 08:18 schrieb Christian Schulte:
> Once more I asked someone to test a snapshot and provided a link to
> Jenkins. That's where all those commits come from. I hope I'll get
> feedback on this one and that could again lead to commits. Doing this on
> a release branch - yes - I got that.
And you do want someone grabbing that snapshot to get all changes done
by all committers and not just some build of some personal branch which
is lacking all other development. Let master be the release branch but
let there be a branch all development of all committers is taking place.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/01/17 um 07:52 schrieb Christian Schulte:
> Number of fixes to plugin POMs was lower than 10 commits. During all of
> this quite a few other bugs have been identified in the core, the ITs,
> the plugins, the plugin ITs, etc.
Last issue I created in JIRA due to this is:
<https://issues.apache.org/jira/browse/MNG-6141>
Once more I asked someone to test a snapshot and provided a link to
Jenkins. That's where all those commits come from. I hope I'll get
feedback on this one and that could again lead to commits. Doing this on
a release branch - yes - I got that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/31/16 um 12:13 schrieb Guillaume Bou�:
>
> 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;
It's the bug fixing that has lead to resetting various master branches.
Someone grabs a recent snapshot, notices it does not work for him,
starts to bisect core although I stated multiple times that current core
is uncovering bugs in the poms. Current master is passing all core ITs,
all plugin ITs and also can be used to build all plugins, if you
manually change to a different plugin tools release
(-DmavenPluginToolsVersion=3.3 or 3.5). Download Maven 3.0-alpha-1 and
try it with that. Current master is a snapshot - that's pre alpha - and
is in a way better conditition than what got released as Maven 3 alpha,
beta and the first 3.0.x releases. We would have to release a few
plugins so that we can upgrade the default plugin version in the core to
those releases and we would then be ready to release that as 3.4.0.
Number of fixes to plugin POMs was lower than 10 commits. During all of
this quite a few other bugs have been identified in the core, the ITs,
the plugins, the plugin ITs, etc. All of this is fixed. We are now
resetting all of this only because there is no trust. Committing to
master means there must be consensus *before* things get committed. It
does not make sense to put any effort into fixing bugs if all this gets
you is requests to revert and endless discussions about everything.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
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 <ti...@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.connolly@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.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?
>
> > >>>>
>
> > >>>
>
> > > 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-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
>
> > >>
>
> > >>
>
> > >
>
> > > ---
>
> > > 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-unsubscribe@maven.apache.org
>
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
> > >
>
> > >
>
> >
>
> > --
>
> > Sent from my phone
>
> >
>
>
>
>
>
>
>
> --
>
> Cheers
>
> Tibor
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Tibor Digana <ti...@googlemail.com>.
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.connolly@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.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?
> >>>>
> >>>
> > 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-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
> >>
> >>
> >
> > ---
> > 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>
--
Cheers
Tibor
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
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 <he...@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-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
>>
>>
>
> ---
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Guillaume Boué <gb...@apache.org>.
Le 30/12/2016 � 09:01, Robert Scholte a �crit :
> On Thu, 29 Dec 2016 18:57:56 +0100, Herv� BOUTEMY
> <he...@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\u2122 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.
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).
>>>
>>> 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? 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...
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).
>>>
>>> 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
>
---
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-31 um 19:28 schrieb Stephen Connolly:
> Well I think syncing patch versions is pointless but as consumers outside
> of Maven are rare it might actually help to keep major.minor aligned... esp
> if we are doing a reset of resolver (if we have a release of resolver
> already cut)
>
> If we have not cut a resolver release then I'm fine with starting resolver
> at 1.0... but if we are dealing with having resolver releases with a
> revert, we'll at least need to jump to 2.0...
+1 on the 2.0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
Well I think syncing patch versions is pointless but as consumers outside
of Maven are rare it might actually help to keep major.minor aligned... esp
if we are doing a reset of resolver (if we have a release of resolver
already cut)
If we have not cut a resolver release then I'm fine with starting resolver
at 1.0... but if we are dealing with having resolver releases with a
revert, we'll at least need to jump to 2.0...
On Sat 31 Dec 2016 at 16:50, Robert Scholte <rf...@apache.org> wrote:
> It is a separate component, just like wagon. Don't think there's a need to
>
> sync those versions.
>
>
>
> On Sat, 31 Dec 2016 17:48:25 +0100, Stephen Connolly
>
> <st...@gmail.com> wrote:
>
>
>
> > I think we should also align our resolver release version on 3.5.0 if we
>
> > do
>
> > the reset... wdyt?
>
> >
>
> > On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY <he...@free.fr>
> wrote:
>
> >
>
> >> looks like 1.1.0 was released without tagging the repo: no tag even in
>
> >> Eclipse
>
> >>
>
> >> git [1]. I hope it is a state that is in git, even without tag: if
>
> >> someone
>
> >> can
>
> >>
>
> >> define the git hash, it would be useful to add a tag, just for reference
>
> >>
>
> >>
>
> >>
>
> >> I don't know who uses Aether 1.1.0.
>
> >>
>
> >>
>
> >>
>
> >> And why are you saying that MRESOLVER-9 is released in 1.1.0?
>
> >>
>
> >> Code imported to Apache is the latest available at Eclipse, and I
>
> >> tagged it
>
> >>
>
> >> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
>
> >>
>
> >> monthes after 1.1.0 release
>
> >>
>
> >>
>
> >>
>
> >> Regards,
>
> >>
>
> >>
>
> >>
>
> >> Hervé
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> [1] http://git.eclipse.org/c/aether/aether-core.git/refs/
>
> >>
>
> >>
>
> >>
>
> >> [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
>
> >>
>
> >> 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
>
> >>
>
> >>
>
> >>
>
> >> [3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
>
> >>
>
> >> 1ee92862c67ec98564c4d8be1207355960f1dd5d
>
> >>
>
> >>
>
> >>
>
> >> Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
>
> >>
>
> >> > Am 12/30/16 um 09:01 schrieb Robert Scholte:
>
> >>
>
> >> > > 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.
>
> >>
>
> >> >
>
> >>
>
> >> > Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
>
> >>
>
> >> > know if that got committed to the repository imported to Apache.
>
> >>
>
> >> >
>
> >>
>
> >> > <
>
> >>
> http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>
> >>
>
> >> >
>
> >>
>
> >> >
>
> >>
>
> >> > ---------------------------------------------------------------------
>
> >>
>
> >> > 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
>
> >>
>
> >>
>
> >>
>
> >> --
>
> > Sent from my phone
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Robert Scholte <rf...@apache.org>.
It is a separate component, just like wagon. Don't think there's a need to
sync those versions.
On Sat, 31 Dec 2016 17:48:25 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> I think we should also align our resolver release version on 3.5.0 if we
> do
> the reset... wdyt?
>
> On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY <he...@free.fr> wrote:
>
>> looks like 1.1.0 was released without tagging the repo: no tag even in
>> Eclipse
>>
>> git [1]. I hope it is a state that is in git, even without tag: if
>> someone
>> can
>>
>> define the git hash, it would be useful to add a tag, just for reference
>>
>>
>>
>> I don't know who uses Aether 1.1.0.
>>
>>
>>
>> And why are you saying that MRESOLVER-9 is released in 1.1.0?
>>
>> Code imported to Apache is the latest available at Eclipse, and I
>> tagged it
>>
>> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
>>
>> monthes after 1.1.0 release
>>
>>
>>
>> Regards,
>>
>>
>>
>> Hervé
>>
>>
>>
>>
>>
>> [1] http://git.eclipse.org/c/aether/aether-core.git/refs/
>>
>>
>>
>> [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
>>
>> 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
>>
>>
>>
>> [3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
>>
>> 1ee92862c67ec98564c4d8be1207355960f1dd5d
>>
>>
>>
>> Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
>>
>> > Am 12/30/16 um 09:01 schrieb Robert Scholte:
>>
>> > > 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.
>>
>> >
>>
>> > Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
>>
>> > know if that got committed to the repository imported to Apache.
>>
>> >
>>
>> > <
>> http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>>
>> >
>>
>> >
>>
>> > ---------------------------------------------------------------------
>>
>> > 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
>>
>>
>>
>> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
I think we should also align our resolver release version on 3.5.0 if we do
the reset... wdyt?
On Sat 31 Dec 2016 at 16:37, Hervé BOUTEMY <he...@free.fr> wrote:
> looks like 1.1.0 was released without tagging the repo: no tag even in
> Eclipse
>
> git [1]. I hope it is a state that is in git, even without tag: if someone
> can
>
> define the git hash, it would be useful to add a tag, just for reference
>
>
>
> I don't know who uses Aether 1.1.0.
>
>
>
> And why are you saying that MRESOLVER-9 is released in 1.1.0?
>
> Code imported to Apache is the latest available at Eclipse, and I tagged it
>
> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
>
> monthes after 1.1.0 release
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
>
>
> [1] http://git.eclipse.org/c/aether/aether-core.git/refs/
>
>
>
> [2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
>
> 4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
>
>
>
> [3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
>
> 1ee92862c67ec98564c4d8be1207355960f1dd5d
>
>
>
> Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
>
> > Am 12/30/16 um 09:01 schrieb Robert Scholte:
>
> > > 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.
>
> >
>
> > Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
>
> > know if that got committed to the repository imported to Apache.
>
> >
>
> > <
> http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > 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
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/31/16 um 17:36 schrieb Herv BOUTEMY:
> looks like 1.1.0 was released without tagging the repo: no tag even in Eclipse
> git [1]. I hope it is a state that is in git, even without tag: if someone can
> define the git hash, it would be useful to add a tag, just for reference
>
> I don't know who uses Aether 1.1.0.
>
> And why are you saying that MRESOLVER-9 is released in 1.1.0?
> Code imported to Apache is the latest available at Eclipse, and I tagged it
> [2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
> monthes after 1.1.0 release
>
The 1.1.0 release came from this repository.
<https://github.com/jvanzyl/aether-core>
It has the bugfix to MRESOLVER-9. That are months before the import to
Apache and months before there has been a bugtracker in place etc. It
nearly took a year for such a fix to arive @Apache. And we are still not
going to ship it this decade.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Hervé BOUTEMY <he...@free.fr>.
looks like 1.1.0 was released without tagging the repo: no tag even in Eclipse
git [1]. I hope it is a state that is in git, even without tag: if someone can
define the git hash, it would be useful to add a tag, just for reference
I don't know who uses Aether 1.1.0.
And why are you saying that MRESOLVER-9 is released in 1.1.0?
Code imported to Apache is the latest available at Eclipse, and I tagged it
[2]: and you committed MRESOLVER-9 yourself to Apache import [2] 2 a few
monthes after 1.1.0 release
Regards,
Hervé
[1] http://git.eclipse.org/c/aether/aether-core.git/refs/
[2] https://git1-us-west.apache.org/repos/asf/maven-resolver/commit/
4cf5f7a406b516a45d8bf15e7dfe3fb3849cb87b
[3] https://git-wip-us.apache.org/repos/asf/maven-resolver/commit/
1ee92862c67ec98564c4d8be1207355960f1dd5d
Le vendredi 30 décembre 2016, 15:57:08 CET Christian Schulte a écrit :
> Am 12/30/16 um 09:01 schrieb Robert Scholte:
> > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <he...@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.
>
> Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
> know if that got committed to the repository imported to Apache.
>
> <http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
>
>
> ---------------------------------------------------------------------
> 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
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/30/16 um 09:01 schrieb Robert Scholte:
> On Thu, 29 Dec 2016 18:57:56 +0100, Herv� BOUTEMY <he...@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.
>
Keep in mind that MRESOLVER-9 is already released in 1.1.0. I do not
know if that got committed to the repository imported to Apache.
<http://repo.maven.apache.org/maven2/org/eclipse/aether/aether-impl/1.1.0/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
What hash do we want to reset resolved to?
(We will be *renaming* master in all cases so that the history is
available... just not on master)
On Fri 30 Dec 2016 at 08:02, Robert Scholte <rf...@apache.org> wrote:
> On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <he...@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
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Robert Scholte <rf...@apache.org>.
On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <he...@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
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Hervé BOUTEMY <he...@free.fr>.
perhaps maven-resolver will require same reset
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
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/29/16 um 12:18 schrieb Stephen Connolly:
> 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.
+1 for the reset from me (committer) as long as this does not mean
current master is lost. So please create a branch of current master
before resetting it. There are a lof of issues that can go in unchanged
afterwards.
> Then we can cherry pick the changes that were on the old master that we
> want to have in 3.4.0
I will squash all my commits before picking them by issue. So there will
be only one commit in master for a given issue. And I will not do
anything like that until there is a clear and final list of issues to go
in. If you take a look at MNG-5971, I committed, then started a release
build on Jenkins and then asked the parties involved in MNG-5971 to
test. I am not sure anyone would have build the core himself from a
branch. So I am -1 for personal branches. Let master be the release
branch but please let there be a branch everyone working on the next
release can commit to so that things get tested during development as
much as possible. You can take the recent discussions on dev@ due to
3.4.0-SNAPSHOT as an example for what I mean. All discussions have led
to issues in JIRA. Personally I rate that something positive. Especially
if you take a look at how those issues may affect fundamental Maven design.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
I'm not seeing any objections to the general idea.
On Tuesday I'll post a draft of the vote proposal to this thread... then if
everyone is happy (translation: nobody says "I'm not happy") I'll start the
vote on Wednesday 3rd... usual 72h but I'll probably wait for Monday 9th
Jan before closing (unless we have evidence of a lack of consensus after
72h)
Assuming the vote is successfully, I'll raise the INFRA tickets and we can
hopefully have an RC a couple of days later.
WDYT?
- Stephen
On Thu 29 Dec 2016 at 11:18, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 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
>
--
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/31/16 um 03:27 schrieb Christian Schulte:
> Am 12/29/16 um 13:49 schrieb Robert Scholte:
>> My worries are more about: how to manage which issues should be cherry
>> picked and who decides that list. Otherwise we might end up in the same
>> situation. E.g. do we have to do a vote on the branch (which might cover
>> multiple issues but which are related to the same topic) to decide if it
>> can be merged with the master?
>
> This is what I have in mind. I know my commits. What I would do as soon
> as master has been reset would be to squash my commits as much as
> possible
Per JIRA issue, of course. So one commit to merge into master per JIRA
issue. All of this has been part of the preliminary testing so it really
should be possible there is just one commit per issue without having to
commit something for the same issue afterwards again.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
That is not how Apache works
The PMC vote is only required for policy or releases. Outside of that,
committer votes are what count.
Votes cast always trump votes not cast, and when it comes to commits, -1 is
a veto... any -1 on a commit means thou shall not merge ... one should be
very careful not to -1 a lot as it can be toxic to the community (at which
point we then have to wake up the PMC or else the board might get involved)
I think if we do this reset we need to have a plan. First step should be
what was originally suggested, a simple switch from aether to resolver
without other changes
Then we can start fixing bugs in incremental releases after that
On Sat 31 Dec 2016 at 02:27, Christian Schulte <cs...@schulte.it> wrote:
> Am 12/29/16 um 13:49 schrieb Robert Scholte:
>
> > My worries are more about: how to manage which issues should be cherry
>
> > picked and who decides that list. Otherwise we might end up in the same
>
> > situation. E.g. do we have to do a vote on the branch (which might cover
>
> > multiple issues but which are related to the same topic) to decide if it
>
> > can be merged with the master?
>
>
>
> This is what I have in mind. I know my commits. What I would do as soon
>
> as master has been reset would be to squash my commits as much as
>
> possible and then cast a vote on specific issues (for each single commit
>
> to be merged into master) with the exception that no response means +1.
>
> So instead of the whole PMC needing to agree, not responding means "+1".
>
> That also would mean that if e.g. two PMC members vote -1, all others
>
> implicitly have voted +1 if they did not respond otherwise. WDYT?
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
OT: how you can have a release with a majority of the PMC voting -1
1. The reasons for voting -1 must not relate to the responsibility
delegated by the board to the PMC with respect to the requirements of a
release
2. The majority of votes cast by committers + PMC must be in favour of the
release
3. At least 3 +1 votes from PMC members
4. A PMC member willing to stand up and perform the release finalisation
steps
5. The release manager declaring the vote as passed
Practically if the majority of the PMC is against the release on non-legal
grounds but the majority of the committers is in favour it would signal a
major crack in the *community* which would probably result in the board
getting involved if left festering. Also the release manager would probably
decide to cancel the vote where there is a significant minority against the
release... so it is highly unlikely that such a release would happen... but
it *could*!
On Sat 31 Dec 2016 at 08:58, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> You have misunderstood the Apache way, imho
>
> Votes are only to *confirm* consensus... and the consensus is of the
> *community* (ie everyone on the dev list who steps up to comment)
>
> When it comes to code changes, committers have a veto and the permission
> to commit, so no code changes can happen without the approval of interested
> committers.
>
> When it comes to releases, the PMC has been delegated certain legal
> responsibilities by the board, so you cannot have a release without 3x +1
> by the PMC (technically doesn't matter how much of the PMC votes -1 as long
> as the majority of votes cast by committers + PMC > 0 and you have at least
> 3x +1 by PMC members... but a release manager doing so could be frowned on)
>
>
> On Sat 31 Dec 2016 at 02:37, Christian Schulte <cs...@schulte.it> wrote:
>
> Am 12/31/16 um 03:27 schrieb Christian Schulte:
>
> > Am 12/29/16 um 13:49 schrieb Robert Scholte:
>
> >> My worries are more about: how to manage which issues should be cherry
>
> >> picked and who decides that list. Otherwise we might end up in the same
>
> >> situation. E.g. do we have to do a vote on the branch (which might cover
>
> >> multiple issues but which are related to the same topic) to decide if it
>
> >> can be merged with the master?
>
> >
>
> > This is what I have in mind. I know my commits. What I would do as soon
>
> > as master has been reset would be to squash my commits as much as
>
> > possible and then cast a vote on specific issues (for each single commit
>
> > to be merged into master) with the exception that no response means +1.
>
> > So instead of the whole PMC needing to agree, not responding means "+1".
>
> > That also would mean that if e.g. two PMC members vote -1, all others
>
> > implicitly have voted +1 if they did not respond otherwise. WDYT?
>
> >
>
>
>
> Adding to this: I do not have a deep understanding of the Apache way of
>
> things. Personally, I do not get the point why the users of the software
>
> cannot take part in any of those decisions. I just may not get the
>
> point, of course. Citizens are asked to vote on election day, for
>
> example. Here it's like a dictatorship of those with the power to do so
>
> deciding the future of all others. Don't get me wrong on this please.
>
> English is not my native language and I may not have found the proper
>
> words here.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
> Sent from my phone
>
--
Sent from my phone
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
You have misunderstood the Apache way, imho
Votes are only to *confirm* consensus... and the consensus is of the
*community* (ie everyone on the dev list who steps up to comment)
When it comes to code changes, committers have a veto and the permission to
commit, so no code changes can happen without the approval of interested
committers.
When it comes to releases, the PMC has been delegated certain legal
responsibilities by the board, so you cannot have a release without 3x +1
by the PMC (technically doesn't matter how much of the PMC votes -1 as long
as the majority of votes cast by committers + PMC > 0 and you have at least
3x +1 by PMC members... but a release manager doing so could be frowned on)
On Sat 31 Dec 2016 at 02:37, Christian Schulte <cs...@schulte.it> wrote:
> Am 12/31/16 um 03:27 schrieb Christian Schulte:
>
> > Am 12/29/16 um 13:49 schrieb Robert Scholte:
>
> >> My worries are more about: how to manage which issues should be cherry
>
> >> picked and who decides that list. Otherwise we might end up in the same
>
> >> situation. E.g. do we have to do a vote on the branch (which might cover
>
> >> multiple issues but which are related to the same topic) to decide if it
>
> >> can be merged with the master?
>
> >
>
> > This is what I have in mind. I know my commits. What I would do as soon
>
> > as master has been reset would be to squash my commits as much as
>
> > possible and then cast a vote on specific issues (for each single commit
>
> > to be merged into master) with the exception that no response means +1.
>
> > So instead of the whole PMC needing to agree, not responding means "+1".
>
> > That also would mean that if e.g. two PMC members vote -1, all others
>
> > implicitly have voted +1 if they did not respond otherwise. WDYT?
>
> >
>
>
>
> Adding to this: I do not have a deep understanding of the Apache way of
>
> things. Personally, I do not get the point why the users of the software
>
> cannot take part in any of those decisions. I just may not get the
>
> point, of course. Citizens are asked to vote on election day, for
>
> example. Here it's like a dictatorship of those with the power to do so
>
> deciding the future of all others. Don't get me wrong on this please.
>
> English is not my native language and I may not have found the proper
>
> words here.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/31/16 um 03:27 schrieb Christian Schulte:
> Am 12/29/16 um 13:49 schrieb Robert Scholte:
>> My worries are more about: how to manage which issues should be cherry
>> picked and who decides that list. Otherwise we might end up in the same
>> situation. E.g. do we have to do a vote on the branch (which might cover
>> multiple issues but which are related to the same topic) to decide if it
>> can be merged with the master?
>
> This is what I have in mind. I know my commits. What I would do as soon
> as master has been reset would be to squash my commits as much as
> possible and then cast a vote on specific issues (for each single commit
> to be merged into master) with the exception that no response means +1.
> So instead of the whole PMC needing to agree, not responding means "+1".
> That also would mean that if e.g. two PMC members vote -1, all others
> implicitly have voted +1 if they did not respond otherwise. WDYT?
>
Adding to this: I do not have a deep understanding of the Apache way of
things. Personally, I do not get the point why the users of the software
cannot take part in any of those decisions. I just may not get the
point, of course. Citizens are asked to vote on election day, for
example. Here it's like a dictatorship of those with the power to do so
deciding the future of all others. Don't get me wrong on this please.
English is not my native language and I may not have found the proper
words here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/29/16 um 13:49 schrieb Robert Scholte:
> My worries are more about: how to manage which issues should be cherry
> picked and who decides that list. Otherwise we might end up in the same
> situation. E.g. do we have to do a vote on the branch (which might cover
> multiple issues but which are related to the same topic) to decide if it
> can be merged with the master?
This is what I have in mind. I know my commits. What I would do as soon
as master has been reset would be to squash my commits as much as
possible and then cast a vote on specific issues (for each single commit
to be merged into master) with the exception that no response means +1.
So instead of the whole PMC needing to agree, not responding means "+1".
That also would mean that if e.g. two PMC members vote -1, all others
implicitly have voted +1 if they did not respond otherwise. WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
This got lost on the PMC list by mistake
On Thu 29 Dec 2016 at 14:33, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I don't think we need to vote each change, but I do think we need to look
> at a more RTC like model for bigger impact changes.
>
> I think we can trust developer judgement once we have some guidance in
> place
>
> On Thu 29 Dec 2016 at 14:07, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> I agree with the proposed plan and also confirmed both commits SHA1s.
>
>
>
> I think/hope that forcing all changes to feature branches and require a
>
> vote to merge isn't necessary.
>
>
>
> I think changes that affect existing integration tests should require a
>
> vote but I don't think it's practical to discuss/vote all changes. We
>
> should ask developers to describe "bigger" changes on the dev list
>
> before they commit, however, and other developers can request the change
>
> go through a feature branch and vote process. "Smaller" changes can go
>
> right in. Of course, "big" and "small" is subjective, but I think we
>
> need to assume Maven developers generally know what they are doing ;-)
>
>
>
> We also need to ask that each commit on master represents a single
>
> complete logical change, to make individual commits easy to understand
>
> and review. I honestly don't think we have the manpower to review and
>
> groom each commit to perfection upfront, so it is inevitable that some
>
> commits will require follow-up changes, but I hope these will be
>
> exceptions and most of commits on master will be clean and
>
> self-contained changes.
>
>
>
> --
>
> Regards,
>
> Igor
>
>
>
> On Thu, Dec 29, 2016, at 07:49 AM, Robert Scholte wrote:
>
> > thanks Stephen for picking this up.
>
> >
>
> > SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
>
> > * [maven-release-plugin] prepare for next development iteration
>
> >
>
> > Yes, this is the hash I would expect to revert to.
>
> > Based on the date I would expect that maven-its should be reset to
>
> >
>
> > SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
>
> > * [MNG-5840] Argh! tests added but not added to suite
>
> >
>
> > I like the idea of pushing to 3.5.0 to indicate there was something with
>
> > 3.4.x
>
> >
>
> > My worries are more about: how to manage which issues should be cherry
>
> > picked and who decides that list. Otherwise we might end up in the same
>
> > situation. E.g. do we have to do a vote on the branch (which might cover
>
> > multiple issues but which are related to the same topic) to decide if it
>
> > can be merged with the master?
>
> >
>
> > Robert
>
> --
> Sent from my phone
>
--
Sent from my phone
Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Stephen Connolly <st...@gmail.com>.
I'm hoping that people step forward with suggestions and we build a
consensus
IMHO 3.5.0 should be absolute minimum content. Just the switch to resolver
and *maybe* the bug fixes on the launcher scripts and .mvn folder handling.
Aim would be to release 3.5.0 by mid-Jan
3.5.x is less of a rush, as I would hope for us to cut that say end of Feb
and start a 6 week cadence (assuming I can get a KT on how to release core
from JvZ)
3.6.x / 4.x.y really depends on what features we want to add
5.x.y will require at least my completion of my proposals and then some
debate... before we actually start to lock down what we really want to do
(remember my proposals are just *my* proposals... they have no weight other
than one committer saying "I think this is what we should do"). I am
writing my proposals because it is much easier to edit a draft (or write a
counter-proposal) than to start from a blank sheet of paper.
- Stephen
On Sat 31 Dec 2016 at 20:28, Robert Scholte <rf...@apache.org> wrote:
>
>
>
>
>
>
> Thanks,
>
> what I'm missing is how people can provide there suggestions.
> E.g. a wiki table where everybody add his own column with preferred
> version?
> Or anonymous to somebody (you as initiator? me as chairman?) so people
> aren't driven by others choices.
> Or any other way.
> For the first 2 options you must specify a period to respond, I would
> expect at least a week due to the time of year.
>
> Robert
>
> On Sat, 31 Dec 2016 21:11:12 +0100, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> Robert, I posted the bug scrub to the dev list
>
> On 31 December 2016 at 19:19, Robert Scholte <rf...@apache.org> wrote:
>
>
>
>
>
>
>
> I could do that. However, if that list results in a new discussion I'm not
> in the position to make a final statement anymore.
>
> Robert
>
> On Sat, 31 Dec 2016 17:27:18 +0100, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> Ok so we will need to do a scrub. Can somebody propose a draft scrub?
>
> Basically, go through the commits we have, identify the JIRA issues
> (creating new ones if necessary) and then produce a table with JIRA issue
> and then proposed version from the set: 3.5.0, 3.5.x, 3.6.x, 4.x.y, 5.x.y
> and WONTFIX
>
> We can then debate the table as a whole and decide the plan
>
> (Not sure if table should be on mailing list or a wiki page... but once we
> decide the plan we should apply the plan in JIRA)
>
> On Sat 31 Dec 2016 at 16:14, Hervé BOUTEMY <he...@free.fr> wrote:
>
> I think we won't avoid to pre-define a short list of issues that are
>
> controversial before working on code reset, to be sure we all agree, or
> either
>
> we'll work too much on branches with associated votes (which won't work
> given
>
> the amount of work to come), either there will be reverts because "this one
>
> requires branch work"
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
> Le jeudi 29 décembre 2016, 13:49:46 CET Robert Scholte a écrit :
>
> > thanks Stephen for picking this up.
>
> >
>
> > SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
>
> > * [maven-release-plugin] prepare for next development iteration
>
> >
>
> > Yes, this is the hash I would expect to revert to.
>
> > Based on the date I would expect that maven-its should be reset to
>
> >
>
> > SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
>
> > * [MNG-5840] Argh! tests added but not added to suite
>
> >
>
> > I like the idea of pushing to 3.5.0 to indicate there was something with
>
> > 3.4.x
>
> >
>
> > My worries are more about: how to manage which issues should be cherry
>
> > picked and who decides that list. Otherwise we might end up in the same
>
> > situation. E.g. do we have to do a vote on the branch (which might cover
>
> > multiple issues but which are related to the same topic) to decide if it
>
> > can be merged with the master?
>
> >
>
> > Robert
>
>
>
>
>
> --
> Sent from my phone
>
>
>
>
>
>
>
>
>
>
>
> --
Sent from my phone
Re: [DISCUSS] Resetting Master branch to
737de43e392fc15a0ce366db98d70aa18b3f6c03
Posted by Robert Scholte <rf...@apache.org>.
thanks Stephen for picking this up.
SHA-1: 737de43e392fc15a0ce366db98d70aa18b3f6c03
* [maven-release-plugin] prepare for next development iteration
Yes, this is the hash I would expect to revert to.
Based on the date I would expect that maven-its should be reset to
SHA-1: 94bd771c88cc96014ca0ddaa07ac6f778b3c7501
* [MNG-5840] Argh! tests added but not added to suite
I like the idea of pushing to 3.5.0 to indicate there was something with
3.4.x
My worries are more about: how to manage which issues should be cherry
picked and who decides that list. Otherwise we might end up in the same
situation. E.g. do we have to do a vote on the branch (which might cover
multiple issues but which are related to the same topic) to decide if it
can be merged with the master?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org