On 19 February 2014 11:05, Fred Cooke <fred.co...@gmail.com> wrote: > Sorry, still working on your first email in this thread which never > explicitly stated that, only implicitly, if your read the URL linked to, > AND happened to know what state 3.2.X was in.
No worries > You did indeed point this out > at a later date. My mistake. But the first email set the tone, which is > hard to shake :-) > Yes well there was a disconnect between what I was thinking I wrote and the words that were written. I hope it has been cleared up! Certainly I think there is a potential difference of opinion between Jason and I as to what kinds of things should be in scope for 3.2.2... my view is backwards compatible bug fixes only... from the issues in JIRA Jason would seem to permit API and behaviour changes... something that I think should be 3.3.x My intent was that once 3.2.1 is released, Jason would switch master to 3.3.0-SNAPSHOT and everyone can start batting off the issues in the bucket for 3.3.0. Jason would continue to be RM for 3.3.x if he wants to. I would take up maintenance of 3.2.x which would be bug fixes *only* and act as RM for that branch, with any back ported bugfixes lasting at most 1 week before I cut an RC and call a vote. There may be no backported bugfixes... or there may be 3-4 per week... but users will have the confidence that if there is a bug that gets fixed for 3.2.x they can upgrade to get the fix. If I am a user looking at what version of Maven to pick, I see 2.2.1 2009/11/08 (5 months) 3.0 2010/10/08 (11 months) 3.0.1 2010/11/26 (2 months) 3.0.2 2011/01/12 (2 months) 3.0.3 2011/03/04 (2 months) 3.0.4 2012/1/20 (11 months) 3.0.5 2013/02/23 (13 months) 3.1.0 2013/07/15 (5 months) 3.1.1 2013/10/04 (3 months) 3.2.1 2014/02/?? (5 months) Why would I pick 3.2.1? It does not look like there is any likelihood of a release soon if there is a bug in 3.2.1 from the past history I'd expect to be waiting between 4 months and a year before the next release... I would be far better to pick a version that is a known quantity, something like 3.0.5 or maybe 3.1.1... Now if we are saying, any bugs found and fixed for 3.2.x will have a release within 1 week of the fix landing in the 3.2.x maintenance branch... how does that shape your view? And in 6-8 weeks when there have been 3 patch releases of 3.2.x and there is now a 3.3.0 released with (if the 3.2 experiment proves successful) a corresponding promise for 3.3.x (I'd propose to stop maintenance of 3.2.x about 4-6 weeks after 3.3.x starts such a maintenance mode, leaving 3.2.x for security related fixes only) I think you'd have a lot more confidence in moving up to a newer maven. Enterprises will move to versions that they perceive as low risk. A true maintenance mode with a regular predictable release cadence where critical issues can get fixed fast will give them low risk. Potential contributors will submit their pull requests or patches and see those end up in a release version and be encouraged to contribute even more. On top of that, I get pissed off by crappy processes, so our releasing maven core will become more streamlined... So to me this is a Win Win Win Win All based on my view that 3.2.x should be for backwards compatible bug fixes only... if I am wrong then there is no point trying for this faster release model. -Stephen > > > On Thu, Feb 20, 2014 at 12:00 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 19 February 2014 10:13, Fred Cooke <fred.co...@gmail.com> wrote: > > > > > You missed the point. No-change commits include: > > > > > > - Clean up white space > > > - Fix some comments in the code base > > > - POM tweaks that don't affect binary output > > > - Light genuine bonafide refactoring that causes no actual change in > > > behaviour at all > > > > > > > Why are those things going into a maintenance release branch? > > > > Whitespace cleanup - not for a maintenance branch. > > > > General comments in the code base - not for a maintenance branch. > > > > Now fixing javadoc comments because they are incorrect... that's a bug... > > and the updated API should be published so that is releasable. > > > > Genuine refactoring that causes no actual change in behaviour at all > should > > never go into a maintenance branch... unless it is necessary to cherry > pick > > the fix of a bug... in which case it is part of the cherry pick and > > associated with fixing a bug > > > > The maintenance release branch should only get bug fixes that are > backwards > > compatible. Those things go into the mainline for the next minor/major > > release. > > > > > > > > > > There is zero point to releasing these things. > > > > > > Fred. > > > > > > > > > On Wed, Feb 19, 2014 at 10:46 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > On 18 February 2014 22:49, Fred Cooke <fred.co...@gmail.com> wrote: > > > > > > > > > Perhaps a stupid question, however if no change goes in, and it > kicks > > > off > > > > > and gives the same gold star as the previous week, then there's no > > > point > > > > to > > > > > releasing it, because it's the same thing, what takes care of this? > > > > > > > > > > > > It will not work that way. > > > > > > > > In order to establish the downstream jobs and builds in Jenkins you > > need > > > to > > > > use fingerprinting. > > > > > > > > How the jobs work is like this: > > > > > > > > 1. The top job passes if the last commit is not > '[maven-release-plugin] > > > > prepare for next development..." > > > > > > > > It also runs `git rev-parse HEAD > git-commit.txt` and we archive > > and > > > > fingerprint the git-commit.txt file > > > > > > > > 2. The second job is to verify that everything builds. > > > > > > > > It picks up the git revision to build as a build parameter > injected > > > by > > > > the promotion of the top job. > > > > > > > > It generates a throw-away GPG key and runs the build with the > full > > > > apache-release profile enabled. > > > > i.e. release:prepare will work if this build passes. > > > > > > > > At the end of its build it runs `git rev-parse HEAD > > > git-commit.txt` > > > > and we archive and fingerprint the git-commit.txt file > > > > > > > > It also triggers the third job with a parameter indicating which > > > build > > > > of the second job triggered the third job. > > > > > > > > It also adds a "builds" promotion to the first job (green star) - > > > note > > > > that the star will be added to the first build that introduced the > > > matching > > > > `git-commit.txt` > > > > > > > > 3. The third job is to verify the integration tests > > > > > > > > It copies the maven distribution and `git-commit.txt` files from > > the > > > > build of the second job provided by the parameter and then runs the > > > > integration tests > > > > > > > > At the end of the build we archive the git-commit.txt and add a > > > > "integration tests pass" promotion to the first job (gold star) - > note > > > that > > > > the star will be added to the first build that introduced the > matching > > > > `git-commit.txt` > > > > > > > > So week 1 there are no changes since the last release. Job 1 Build 1 > > > fails, > > > > nothing else happens > > > > > > > > Week 2, there are changes since the last release. Job 1 Build 2 > passes, > > > Job > > > > 2 Build 1 fails, nothing else happens > > > > > > > > Week 3, there are no changes since week 2. Job 1 Build 3 passes, Job > 2 > > > > Build 2 fails, nothing else happens > > > > > > > > Week 4, there are changes since week 3. Job 1 Build 4 passes, Job 2 > > > Build 3 > > > > passes, Job 3 Build 1 fails. Job 1 Build 4 gets a green star. (The > > > > integration tests broke because of a broken integration test) > > > > > > > > Week 5, there are no changes since week 4 (but the integration test > is > > > now > > > > fixed). Job 1 Build 5 passes, Job 2 Build 4 passes, Job 3 Build 2 > > passes. > > > > Job 1 Build 4 now gets a gold star. Job 1 Build 5 has no stars as it > > did > > > > not introduce a new git-commit.txt. Email gets sent to the dev list. > > > Nobody > > > > bothers their arse to cut a release > > > > > > > > Week 6, there are no changes since week 4. Job 1 Build 6 passes, Job > 2 > > > > Build 5 passes, Job 3 Build 3 passes. Nothing else happens as Job 1 > > > Build 4 > > > > already has green and gold stars and that was the first job to > > introduce > > > > the specific git-commit.txt > > > > > > > > Week 7, there are changes since week 6. Job 1 Build 7 passes, Job 2 > > > Build 6 > > > > passes, Job 3 Build 4 passes. Job 1 Build 7 now gets both green and > > gold > > > > stars. Email gets sent to the dev list. > > > > > > > > The behaviour is perhaps a bit smarter than you might have thought > ;-) > > > > > > > > > > > > > Just > > > > > the human going "well, actually there were no commits, so this > email > > is > > > > > spurious"? > > > > > > > > > > I see no problem with a thorough test rig like this, though. It > seems > > > > > purely positive. And if phrased more like "This gold star means > it's > > OK > > > > to > > > > > make a release" as opposed to "This gold star means a human should > > > think > > > > > about making a release" then it'd provoke no technical offense, > > > > probably. > > > > > > > > > > Releases are inherently human. It could be that it gold star with 3 > > out > > > > of > > > > > a 5 commit patch that makes no sense to release, even if it passes > > all > > > > > tests (tests missing?). You get a release out by making a clear > > > decision > > > > > about what will be in it, working towards that solidly, and not > > > creeping > > > > to > > > > > other related/new things. If at some point you realise you bit off > > more > > > > > than could be chewed, you trim the excess and re-decide what'll be > in > > > the > > > > > release, which brings it closer, or even to the point of occurring. > > > > > > > > > > My 2c about which I welcome feedback and abuse. :-) > > > > > > > > > > Fred. > > > > > > > > > > > > > > > On Wed, Feb 19, 2014 at 11:19 AM, Stephen Connolly < > > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > > > > On Tuesday, 18 February 2014, Jason van Zyl <ja...@takari.io> > > wrote: > > > > > > > > > > > > > > > > > > > > On Feb 18, 2014, at 11:47 AM, Stephen Connolly < > > > > > > > stephen.alan.conno...@gmail.com <javascript:;>> wrote: > > > > > > > > > > > > > > > Well all this will be for the moment is a reminder that the > > best > > > > > tests > > > > > > we > > > > > > > > have say it is releasable and that a *human* can think about > > > > cutting > > > > > a > > > > > > > > release. > > > > > > > > > > > > > > > > Right now it will fail to notify because there are failing > > > > > integration > > > > > > > > tests (need a 3.2.1 in central to fix the three failing > tests) > > > > > > > > > > > > > > > > If we switch master to a 4.x line I will switch the job to > > follow > > > > the > > > > > > > 3.2.x > > > > > > > > branch. > > > > > > > > > > > > > > > > > > > > > > I think that will be a few weeks as I'm in the middle of trying > > to > > > > > punch > > > > > > > out flipping the core to jsr330, refactor some of the > resolution > > > and > > > > > get > > > > > > us > > > > > > > to a place where we can make a punch list of what we're going > to > > > > eject > > > > > > from > > > > > > > the core. I think once everything is marked as deprecated we'll > > > have > > > > to > > > > > > > make some decisions about what we're going to nuke for the > 4.x. I > > > > think > > > > > > we > > > > > > > need to make at least one release once everything is > deprecated, > > > > maybe > > > > > it > > > > > > > doesn't matter. > > > > > > > > > > > > > > > What I want this to do is ensure that any fixes for 3.2.x get > > > > > released > > > > > > > > quickly. > > > > > > > > > > > > > > > > > > > > > > Sure, I don't disagree but again I think it's curating the > issues > > > and > > > > > > > having something to release. The core issue is having something > > to > > > > > > release. > > > > > > > > > > > > > > > > > > Which is what the build chain establishes. If the hash gets a > gold > > > > star, > > > > > we > > > > > > have something to consider releasing and a mail suggesting that > we > > > > should > > > > > > cut a release > > > > > > > > > > > > > > > > > > > I plan to work on the 3.2.2 list and maybe we agree to leave > it > > > that > > > > > > size > > > > > > > and when it's done release it. I would rather agree that a set > of > > > > > issues > > > > > > > are in a release and release it when it's done, and if it's > > taking > > > > too > > > > > > long > > > > > > > shear off some issues and release. > > > > > > > > > > > > > > > The major changes will be towards 4.x, where a slower release > > > cycle > > > > > is > > > > > > > fine. > > > > > > > > > > > > > > > > Given that 3.2.x should only have bug fixes how do you see > this > > > as > > > > > > risky? > > > > > > > > > > > > > > That it's releasing for releasing sake, and not trying to > address > > > the > > > > > > real > > > > > > > issue of lack of movement in the core. I think if you fix some > > bugs > > > > > it's > > > > > > > fine for them to collect over 6 weeks. The vast majority of > users > > > are > > > > > in > > > > > > > organizations where there is no way they are going to absorb > > these > > > > > > changes. > > > > > > > For people who are heavily involved can take CI builds and try > > > them, > > > > > > > otherwise a 6 weeks cadence I believe is quite good. > > > > > > > > > > > > > > > If anything it means that if you fix a bug in 3.2.x it will > be > > > > > released > > > > > > > > quickly... 3.2.x has taken far far too long. > > > > > > > > > > > > > > By what measure? > > > > > > > > > > > > > > > > > > It was supposed to be a quick release the first week if Oct > 2013... > > > We > > > > > > still have not released it > > > > > > > > > > > > > > > > > > > > > > > > > > > High cadence when there are > > > > > > > > changes to release is a better way. > > > > > > > > > > > > > > Again high cadence compared to what? > > > > > > > > > > > > > > > > > > Compared to our average cadence over the past N years. > > > > > > > > > > > > This is a three month experiment. If it doesn't work we will try > > > > > something > > > > > > else. If the rest if the PMC gets pissed off then the releases > will > > > not > > > > > get > > > > > > enough binding voted and it will come to a natural halt > > > > > > > > > > > > Previously you have suggested a 4-6 week cadence... That cadence > > > failed > > > > > to > > > > > > deliver... Weekly is probably the fastest cadence you can have at > > ASF > > > > > (and > > > > > > it may prove to be too fast for ASF) but we won't know unless we > > try. > > > > > > > > > > > > So I am suggesting that we try shipping code as fast as we can > and > > > step > > > > > > back if that speed isn't working > > > > > > > > > > > > > > > > > > > > > I will act as RM if nobody else steps > > > > > > > > up during this 3 month experiment (but I would encourage > other > > > > > > committers > > > > > > > > to pick up the role for practice) > > > > > > > > > > > > > > So you're deciding I'm not the RM now after having done the > last > > > two > > > > > > > releases? How does that work? > > > > > > > > > > > > > > > > > > The RM has always been whoever stands up and says "I am cutting a > > > > > release" > > > > > > > > > > > > I was just saying that if it is too much effort for you, I am > > willing > > > > to > > > > > > step up and cut the release. > > > > > > > > > > > > If you want to cut the releases, super. But I recognise that > > cutting > > > > > > releases is work and switching to (max) one per week may be too > > much > > > of > > > > > an > > > > > > ask for you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Stephen > > > > > > > > > > > > > > > > On Tuesday, 18 February 2014, Jason van Zyl <ja...@takari.io > > > > > > <javascript:;>> > > > > > > > wrote: > > > > > > > > > > > > > > > >> Sorry, but I don't think this is a good way to do releases. > > > > > Honestly I > > > > > > > >> think it's a potential recipe for disaster. > > > > > > > >> > > > > > > > >> As I said before, it's the lack of work being done in the > core > > > > that > > > > > is > > > > > > > the > > > > > > > >> issue. Releases aren't being made because until recently > there > > > > > isn't a > > > > > > > lot > > > > > > > >> of activity in the core. Just jumping into weekly releases > is > > > not > > > > > the > > > > > > > >> solution for having not released for 3 months. > > > > > > > >> > > > > > > > >> The issues need to be curated, a lot more tests need to > done, > > > and > > > > a > > > > > > good > > > > > > > >> chunk of the core needs to be cleaned up before having more > > > > frequent > > > > > > > >> releases. Having a public weekly release I don't think is > > going > > > to > > > > > be > > > > > > > >> helpful. I think shooting for a release every 4-6 weeks as > > > > official > > > > > > > >> releases is a good start, and then patch releases possibly > > more > > > > > > > frequent. > > > > > > > >> > > > > > > > >> I'm not in favor of this and I think it's too drastic a > change > > > and > > > > > > isn't > > > > > > > >> going to help. > > > > > > > >> > > > > > > > >> On Feb 18, 2014, at 7:26 AM, Stephen Connolly < > > > > > > > >> stephen.alan.conno...@gmail.com <javascript:;> > > <javascript:;>> > > > > > wrote: > > > > > > > >> > > > > > > > >>> I have set up a chain of build jobs in Jenkins. > > > > > > > >>> > > > > > > > >>> The root of the chain is > > > > > > > >>> https://builds.apache.org/job/maven-3.2-release-status/ > > > > > > > >>> > > > > > > > >>> This builds at midnight UTC every monday. > > > > > > > >>> > > > > > > > >>> If there are changes to the master branch of Maven since > the > > > last > > > > > > > release > > > > > > > >>> of Maven then that build will pass and kick off the chain. > > > > > > > >>> > > > > > > > >>> The next build in the chain is > > > > > > > >>> > > https://builds.apache.org/job/maven-3.2-release-status-build/ > > > > > > > >>> > > > > > > > >>> This checks out the GIT hash provided by > > > > > > > >>> https://builds.apache.org/job/maven-3.2-release-status/and > > > > > verifies > > > > > > > >> that > > > > > > > >>> it builds using the apache-release profile (and a throwaway > > GPG > > > > key > > > > > > to > > > > > > > >> sign > > > > > > > >>> everything - we need a GPG key to enable the profile) > > > > > > > >>> > > > > > > > >>> If that build succeeds then > > > > > > > >>> > https://builds.apache.org/job/maven-3.2-release-status/gets a > > > > > green > > > > > > > >> star > > > > > > > >>> promotion badge and > > > > > > > >>> > > > https://builds.apache.org/job/maven-3.2-release-status-test/gets > > > > > > > >> triggered. > > > > > > > >>> > > > > > > > >>> > > > https://builds.apache.org/job/maven-3.2-release-status-test/uses > > > > > > the > > > > > > > >> built > > > > > > > >>> version of Apache Maven from > > > > > > > >>> > > > https://builds.apache.org/job/maven-3.2-release-status-build/and > > > > > > runs > > > > > > > >> the > > > > > > > >>> integration tests against that binary. > > > > > > > >>> > > > > > > > >>> If that build succeeds then > > > > > > > >>> > https://builds.apache.org/job/maven-3.2-release-status/gets a > > > > > gold > > > > > > > star > > > > > > > >>> promotion badge. > > > > > > > >>> > > > > > > > >>> After Monday, if it all works according to plan, then I > will > > > > tweak > > > > > > the > > > > > > > >> job > > > > > > > >>> to send an email on success alerting us that we can cut a > > > release > > > > > of > > > > > > > >> Maven > > > > > > > >>> core. > > > > > > > >>> > > > > > > > >>> I would hope that a release manager would step forward (it > > may > > > be > > > > > > me... > > > > > > > >> it > > > > > > > >>> could be anyone who feels up to cutting a release) and we > > would > > > > > then > > > > > > > cut > > > > > > > >> a > > > > > > > >>> release sometime after the mail. > > > > > > > >>> > > > > > > > >>> If there is no gold star on the build... then there will > not > > > be a > > > > > > > release > > > > > > > >>> that week... or at least I will not be pushing for one. > > > > > > > >>> > > > > > > > >>> If this pipeline works out ok, we can see about enhancing > it > > > with > > > > > > > further > > > > > > > >>> tests, e.g. windows integration tests, etc. > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> > > > > > > > >> Jason > > > > > > > >> > > > > > > > >> ---------------------------------------------------------- > > > > > > > >> Jason van Zyl > > > > > > > >> Founder, Apache Maven > > > > > > > >> http://twitter.com/jvanzyl > > > > > > > >> http://twitter.com/takari_io > > > > > > > >> --------------------------------------------------------- > > > > > > > >> > > > > > > > >> Simplex sigillum veri. (Simplicity is the seal of truth.) > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > > > > Sent from my phone > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > > Jason van Zyl > > > > > > > Founder, Apache Maven > > > > > > > http://twitter.com/jvanzyl > > > > > > > http://twitter.com/takari_io > > > > > > > --------------------------------------------------------- > > > > > > > > > > > > > > Three people can keep a secret provided two of them are dead. > > > > > > > > > > > > > > -- Benjamin Franklin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sent from my phone > > > > > > > > > > > > > > > > > > > > >
