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
