My (more than) 2 cents on this topic. It's going to be really interesting to see how the board decides on this sort of thing.
Your plan is completely logical. Plenty of business operate this way like newspapers and car manufacturers. Everybody knows when the next "release" is. Car manufacturers release next year's models before the absolute end of the year maybe to buy some wiggle room if there is a major defect found, but there is no skipping a year. And newspapers can't really skip a day either. So they ship with hopefully minor bugs and newspapers print corrections and car manufacturers recall your car. I remember reading once that 97% of all cars have been recalled for some issue. And I get how having a schedule helps coordinate the core volunteers. But what is Cordova's plan if a major defect is found too late for the "schedule"? Would you skip a release? And what if something more subjective comes up like a some user showing up at the last minute and saying they don't like the usability or name of something and a grass roots movement grows around it. Somewhere along the way, I picked up the notion that the 72 hour vote was for the non-core. That Apache communities have folks who are busy with their day jobs and can't always get to respond in 24 hours. Several folks have alluded to this in the various threads, but nobody has said that it is "policy". If you are a house builder, I don't think you can buy a piece of property and start building a house. I'm pretty sure you have to post Public Notice signs on the property and in the paper and hold a public hearing about whether you can use the land to build the house you want to build. Around where I live, I rarely ever see anything get fully rejected, and there seems to be a faction that wants to fight any development and maybe this process is just so they can feel heard, but it seems to be the process. My sense is that Apache wants us to work this way, but the question is whether we "must". Having a four day manufacturing pipeline is definitely problematic (3 days for voting, 1 day for mirror propagation) for rapid releases, especially since many other open source organizations can ship as soon as it is checked in, but maybe this is also part of the Apache Way. We apply an extra coat of paint, or do additional safety checks, or cater to the community members who can't be as active because their working on the project isn't their main job. Thanks for reading, -Alex From: Brian LeRoux <b...@brian.io<mailto:b...@brian.io>> Reply-To: "bo...@apache.org<mailto:bo...@apache.org>" <bo...@apache.org<mailto:bo...@apache.org>> Date: Wednesday, February 12, 2014 7:25 PM To: Apache Board <bo...@apache.org<mailto:bo...@apache.org>> Cc: "dev@community.apache.org<mailto:dev@community.apache.org>" <dev@community.apache.org<mailto:dev@community.apache.org>> Subject: Re: How can we support a faster release cadence? I'd like to throw out some thoughts in support of this thinking and help explore how we can support faster releases at Apache. Cordova has bias to shipping. We started shipping on a schedule mid 2011 and this was a very deliberate choice, after two years of scattered, and frankly reactionary, releases. At that time we called the project PhoneGap and we realized our offering was playing cat and mouse with the very fast moving dependencies of iOS and Android. Being reactionary made shipping a fire drill, inevitably drawn out since we didn't exercise those muscles enough, and ultimately this made our software a risk for adoption. We didn't want to be a risk for adoption. We also did not want our volunteer committership killing themselves every time iOS or Android landed a patch. Moving to a schedule acted as a forcing function to exercise those muscles, find our cadence, and only positives to the code and community resulted. Shipping brought our core together. It meant if we didn't have a fix for a feature the branch would land in the next release which is only a month away. This built huge confidence in our team by our community. Our code become better tested, and more streamlined. A consistent release cadence not only helped us find more quality in our code, but that confidence really helped us build our committer and developer community. The story is hardly unique: Chrome, Ubuntu, Docker, Firefox, and many others have adopted this model in recent years. I feel anything that can be considered a better practice for higher quality code and driving community confidence, and subsequently adoption, really embodies Apache ideals. The current process could be largely automated and the vote doesn't necessarily have to be in the form of an email. I've found these past weeks the act of voting seems near cultural at Apache so I hope that doesn't sound crazy! I mean well. Another issue I am personally unclear on is the wide variety of artifacts destinations that an Apache project can be shipped today. Maven has some of these smarts built in but projects like the npm registry do not. Another area we need to address is the proliferation of various app stores. I'm not a fan of them, but they happen, and we should have a mechanism for our projects to deliver to them. On Fri, Feb 7, 2014 at 3:02 AM, Stephen Connolly <stephen.alan.conno...@gmail.com<mailto:stephen.alan.conno...@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... 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
