On Sat, Feb 8, 2014 at 8:50 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> So it's not true to say that 'community over code' precludes this.
> Some communities have chosen this.
+1 high-cadence releasing should be a community decision.
> All the remarks about code quality and stability are, I think, off
> topic here. The reason for the release system is legal, not QA. If
> people think that more releases, or more automated releases, will
> decrease quality, then they shouldn't adopt those patterns in their
> communities.
Proponents of high-cadence releasing generally make the argument that it
increases quality.
http://martinfowler.com/books/continuousDelivery.html
Long, high intensity releases become a thing of the past.
http://www.stephen-smith.co.uk/release-more-with-less/
However, the benefits of releasing smaller change sets more frequently -
improved feedback, risk, overheards, efficiency, and ownership - are also
operationally advantageous, and this should be viewed as an opportunity to
educate those unaware of the power of batch size reduction.
http://www.pwc.com/us/en/technology-forecast/2013/issue2/interviews/interview-john-esser.jhtml
The absence of serious production problems points to the fact that we're
rolling smaller increments of functionality, and so it's a lot easier to
make sure the quality level is high.
Even if not everyone around here prefers this style of development, it's
plenty well established. Figuring out how best to faciliate its use presents
an opportunity to improve Apache, and I firmly believe that our models are
sufficiently flexible to handle it.
Marvin Humphrey
