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