On 13 February 2014 04:25, 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 agree; in the CouchDB community we had a similar experience. Addressing it has been positive both for our brand and for our community. It's also been a triumph of Apache values of community over code, demonstrating that the incubator process, as well as addressing legal concerns via due diligence, is also capable of sustaining communities who can survive the acrimonious departure of the founder. Moving to a time-driven release has helped us enormously. > 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 faster our code is distributed, the faster we get feedback, as Stephen's also said. > 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: ... >> 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. This last piece is important - I'll bring it up later on. >> 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. Surely 27 hours is a *guidance* not a law. If a project's community wants to run fast then presumably they also have the commit rate to drive this, and a diversity across the community, committers & PMC to feel that this isn't Evil Co sneaking in their cronies. I'm sure that a rogue release or unbalanced PMC will get appropriate board attention in the mid term, if not the short term. >> 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. Personally (as a volunteer committer) that feels tight, but again that's my commitment for CouchDB, and not Cordova or Jenkins or whatever. If we can respect the community concensus then why not a shorter window? The reality is that very few changes/patches land immediately in master 30 seconds before the release, and part of being a PMC member is giving trust to your committers to DTRT in your absence. And if we are releasing weekly then the delta of trust is actually pretty low. Personally, without a full history of the ASF, I don't yet see a specific, concrete example of how this is going to expose the Foundation and/or the Brand. BTW I'm at IETF in London, feel free to school me there in person - I'd love to hear your war stories. >> 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*? Agreed. I'm not convinced that building it by hand, as a PMC member, is magically going to improve the reliability. In fact, if each PMC member or community member sets up a simple test bot or CI on their preferred platform(s) arguably that's better time spent, and a more reliable result as it can be run after every commit, or even before git merging to the release / master branch. However, to pick up the point "package meets the requirements of the ASF policy on releases." from earlier, I don't see how a bot or script can scrutinise a list of commits or diffs, and make a reasoned decision that that code meets ASF requirements from an IP clearance. I might not have phrased that perfectly, but it's one important point that I wasn't aware of until this discussion brewed. Are there other points that should be on Brian & my list? >> 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? I thought this is what the ASF build farm is supposed to enable, surely? >> 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 In addition to Phil & Benson's pithy and timely summaries, - is there a specific example of how faster *releases* have exposed the ASF in the past? - is there some legal finesse that exposes committers or PMC members if weekly tarballs, but not full releases, are made available through some automated process? nightly builds are de rigeur nowadays. - for long term ASF members, is the release cadence something that you *feel* is a per- project decison, assuming the above concerns are taken care of? Hopefully that nails down facts WRT to legal constraints, and also feeling WRT the ASF community. A+ Dave
