community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: How can we support a faster release cadence?
Date Fri, 07 Feb 2014 23:40:00 GMT
Keeping this in public.

We VOTE and review precisely to minimize and catch the IP mistakes that inevitably happen
when people are examining the IP from time to time. The community will care about quality,
but minding the IP protects us all.

RAT check, detailed review and 3 +1 where those involved know how to review the release are
required.

I would have a hard time using an Apache project in production if it were continually changing.
I want a stable version that has no surprises if I choose to build from trunk I can, at my
own risk. I want a version (patched or not) that I have confirmed works for me.

What's doubly funny is that the OP compares this situation to Jenkins a CI system. Many projects
have nightly builds for precisely the reasons the OP is asking weekly releases - to help the
community.

Oh look - https://builds.apache.org/ - it is Jenkins! and here are the latest and greatest
(or not so great) from many projects. These can be shared on the ML but not on project websites
precisely to keep the use to the engaged developer community.

Regards,
Dave

On Feb 7, 2014, at 9:35 AM, Alex Harui wrote:

> IMO, a more important question is:  Does it fit within the "Apache Way" of "Community
over Code" to have a project release on a particular schedule?  Because it feels to me that
if you have a release cadence then you are saying "Clock over Community".
> 
> I get that having a schedule helps many in the community manage their time and expectations,
but I am concerned that a schedule without wiggle room means that there is less subjectivity
to release quality which can be bad.  No matter how long it takes to get from a Release Manager
starting the packaging to getting it on the dist server, someone may find a critical bug in
that window.  Telling them that they have to wait for the next release is "fair" but may not
serve the best interests of the community.
> 
> Then, once you allow subjectivity in a release quality discussion, then I think you have
to give 72 hours because folks are often volunteers and may not have the cycles to respond
in a shorter time frame, but may still have something very important to say, even if you have
your 3 +1 votes already.
> 
> Similarly, there are questions about whether a release manager should be allowed to PGP
sign artifacts created on a CI server.
> 
> And regarding the steps required to approve a release, it has been my experience on every
project I've worked on or used that the bug base has a "unable to reproduce" option that gets
used often enough to make me believe that a few CI/AutomatedTesting servers are not able to
fully certify quality.  IOW, things that work fine on your computer or on the CI or testing
servers simply may not work on some community member's computer.   And providing a window
of time for finding that out is part of the current release policy.
> 
> If you've ever just missed a bus or train, knowing another one is coming soon isn't very
satisfying if you're in a hurry.  If the driver sees you running but looks at his watch and
drives away, how does that make you feel about that person and the company he works for?
> 
> Thanks,
> -Alex
> 
> From: Stephen Connolly <stephen.alan.connolly@gmail.com<mailto:stephen.alan.connolly@gmail.com>>
> Reply-To: "board@apache.org<mailto:board@apache.org>" <board@apache.org<mailto:board@apache.org>>
> Date: Friday, February 7, 2014 3:02 AM
> To: "dev@community.apache.org<mailto:dev@community.apache.org>" <dev@community.apache.org<mailto:dev@community.apache.org>>
> Subject: How can we support a faster release cadence?
> 
> 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 (e.g. http://stats.jenkins-ci.org/jenkins-stats/svg/201312-jenkins.svg)
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 http://www.apache.org/dev/release
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 cast)
> 
> 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 releases
> 
> 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.
> 
> -Stephen
> 
> P.S.
> * 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
> 


Mime
View raw message