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. You did indeed point this out at a later date. My mistake. But the first email set the tone, which is hard to shake :-)
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 > > > > > > > > > > > > > > >
