On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY <herve.bout...@free.fr>
wrote:
perhaps maven-resolver will require same reset
+1
IMO we forgot to do a release with the original Aether code with the new
GAVs.
Robert
and we'll need to define which convention to use on Jira when merging
code:
remove "Fix Version: 3.4.0" for example, to track what features have not
been
merged yet
Regards,
Hervé
Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
On ASF infra, our master branch is supposed to be a protected branch and
thus cannot be reset or force-pushed without an INFRA ticket.
If we want to reset our master branch in order to clean out the history
of
the many changes and reverts to and fro etc, we thus need an INFRA
ticket
raised.
INFRA should not act on such a ticket without the results of a vote of
the
committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)
Votes are a great way to *confirm* consensus, but a horrible way to
build a
community or establish consensus. We should only ever have a vote thread
once the consensus seems to be established.
To establish consensus we use a discuss thread.
Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.
We have not been good at maintaining our CI infrastructure:
* As a consequence, some people have been developing on master rather
than
on branches in order to ensure that their development gets the benefit
of
the integration tests
* This has lead to a lot of micro commits and effectively revert
commits on
master making it hard to track what actually has changed and what has
actually been fixed.
* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes
We have not been good at maintaining our Integration tests:
* As a consequence it has been hard to get our CI infrastructure working
effectively
* As a consequence, people have been forced to leverage a single branch
for
CI testing
We have not been good at developing bigger changes in a branch
etc.
I could go on.
My belief is that confidence in 3.4.0 has been eroded.
I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.
Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0
This will probably also involve:
* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")
* Switching to a culture of branch / PR development for all committers
* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in resolution
of
dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression
* etc
But the first step in that would be to reset master...
So...
Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to reset
to?
What is the correct hash for the integration tests?
Do we want to do this?
What else should we change about our processes to prevent the need to do
this again?
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
