community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: How can we support a faster release cadence?
Date Fri, 07 Feb 2014 11:44:07 GMT
Hi Stephen, @all

I'm not involved in the Maven development, but I enjoy writing plug-ins for 
Jenkins. 

From a plug-in developer point of view, whenever a developer needs a change 
in the Jenkins core, s/he knows that once there is a fix/pull request 
for his issue, it will get released probably within one or two weeks after 
it gets merged into master branch. 

So I imagine that developers of plug-ins for Maven could benefit of having 
shorter release cycles too.

I also see lots of bugs being filed in Jenkins JIRA once a release is 
out. Although it is a good practice to use the LTS, I think many users 
install the latest version. This helps to find bugs before they are 
released in the LTS version (sometimes it's hard to write tests for 
all envs + variables).

So my +1 (probably not binding :) 

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com

>________________________________
> From: Stephen Connolly <stephen.alan.connolly@gmail.com>
>To: dev@community.apache.org 
>Sent: Friday, February 7, 2014 9:14 AM
>Subject: Re: How can we support a faster release cadence?
> 
>
>On 7 February 2014 11:02, Stephen Connolly
><stephen.alan.connolly@gmail.com>wrote:
>
>> 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...
>>
>
>My bad... looking at http://www.apache.org/dev/release I missed
>
>> Please ensure that you wait at least 24 hours after uploading a new
>release before updating the project download page and sending the
>announcement email(s).
>
>So that basically means it could be 4.5 days after the release is cut
>before it is announced as available to users... wait an average of 12h for
>a user to download it, add another 12h for them to identify the bug/issue
>and report it with a test case... That leaves maybe a 1.5 day window for
>the committers to fix the issue the user has...
>
>
>> 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.
>>
>
>The point of a fast cadence is that users know if they have an issue and
>report it reasonably early enough, they will get the fix in the next
>release... if we lose 4.5 days between the cutting of the RC and the [ANN]
>email we can actually harm the community, at least from my experience with
>the Jenkins project with respect to user engagement.
>
>
>
>>
>> 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