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

Reply via email to