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

Reply via email to