community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject How can we support a faster release cadence?
Date Fri, 07 Feb 2014 11:02:56 GMT
One of the projects I am involved with is the Jenkins project. At Jenkins
we cut a release of Jenkins every wednesday... assuming the test all pass...
Not every release is as stable as people might desire (the tests don't
catch everything), hence there is the LTS release line, but none the less,
there is a major release every 7 days... and if you look at the usage stats
most users actually stick fairly close to the latest release.

I have found that this 7 day release cadence can be really helpful for some
code bases.

When I started to think about could we follow this model for the Maven
project as we move towards Maven 4.0, there is one thing that gets in the
way... namely release votes.

The standard answer is that we could publish snapshots... but those are not
indented for use by users... and where the cadence can help is that these
things can be picked up by users.

So what is it that gets in the way with release votes:

* The 72h "soft" requirement for vote duration

* The actions that a PMC member is required to perform before they can
vote. See which states:

    > Before voting +1 PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that the
package meets the requirements of the ASF policy on releases.

So how exactly do these things get in the way?

Well as I see it the 72h vote duration isn't necessarily a big deal... we
need some duration of notice about what is going into the release, there
will always be people who feel the duration is either too short or two
long... but with a 7 day cadence and maybe a few hours before the release
manager closes out the vote and then you wait for the release to finished
syncing to the mirrors and then the release manager gets a chance to verify
that the release has synced to at least one mirror... you could easily lose
half a day's duration in that process... oh look the release is out 3.5
days after it was cut... and we're cutting another one in 3.5 days... it is
likely we will not get much meaningful feedback from users in the remaining
3.5 days... so essentially you end up with a ping-pong of break... skip...
fix since if a bleeding edge user finds an issue in 4.0.56 we will have cut
4.0.57 by the time they report it to us and the fix ends up in 4.0.58...
with a shorter vote duration, say 12h, the bleeding edge user reports the
issue, we fix and the next release is the one they can use.

In the context of a fast cadence, where every committer in the community
knows there will be a release on wednesday cut from the last revision that
passed all the tests on the CI system unless there have been no commits
since the last release that meet that criteria, do we need to wait the full
72h for a vote? Would 12h be sufficient (assuming the 3 PMC +1's get cast
during those 12h... and if not, well just extend until enough votes are

I think this is different use case from my understanding of the concerns
that drove the 72h vote duration convention, as this would not be 3 PMC
members who all work for the same company and are in the same location
conspiring to drive their changes into the release... everything would be
happening in the open and a 12h window mid-week should allow at least 4h of
waking time in any TZ.

So the second issue is what a PMC member is required to do before voting...

As a PMC member you are required to

1. Download the source code package
2. Compile it as provided
3. Test the resulting executable on your own platform
4. Verify that the package meets the requirements of the ASF policy on

Do we really have to personally do all that *by hand*?

Why can we not have a trusted build server hosted on Apache hardware do the
download of the source package, compile it as provided and run the
automated acceptance tests (on a range of platforms), the RAT tooling and
perhaps verify that the source code package matches what is in source
control? The trusted build server could then report the results to the
project mailing list and then the PMC members just need to confirm the
build server said OK, review the commits between the last time they looked
at the commits and the tag (which they know matches what is in the source
bundle) and then vote +1?

The PMC members are supposed to be keeping an eye on the commits anyway, so
that shouldn't be too onerous, and the release manager could even provide a
link to the build server confirmation build in the VOTE email.

I would appreciate any people's thoughts on the above.


* Speaking in my personal capacity as a member of the ASF.
* I am not saying that Maven will move to such a model, or even wants to
move to such a model... more that I was thinking about the issues that
might prevent us if we so desired... I know other projects at Apache are
interested in fast release cadence however, so getting this topic discussed
in the open is no bad thing IMHO

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message