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