I love the release cadence - more projects should do it - and I can understand why you fight anything that you believe would hinder that. But I don't really get how a vote affects that - whatever cycle you're on - it just shifts it 3 days? So if you were cutting a release on the last Friday of every month (for example) - nothing changes for the user except that the monthly release is available 3 days later - they still get it monthly, just on the Monday?
Niall On Thu, Feb 13, 2014 at 3:25 AM, Brian LeRoux <b...@brian.io> wrote: > 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> 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 >> >> >
