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 > > > > > > > > > >