community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Schaefer <joe_schae...@yahoo.com>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 23:05:04 GMT
Frankly the notion that there is empirical evidence that
the standard Apache process is “too slow and buggy” is a straw man.
I have over a decade of personal anecdotal evidence watching
Apache projects self-improve and serve the needs of their
communities rather well.  If anything, I’d say many projects
go too fast already, especially when they are doing a new
major release.  A full week’s soak out on the dev list usually
produces fewer duds in those circumstances.

I don’t deny that there is literature that says faster releases
are ‘better’, but that observation lacks a base point relative
to Apache processes.  Clearly we can all agree that there is 
a notion of going “too fast”, going “too slow”, and a desire amongst
some people to “go faster”, but those are entirely subjective
and seemingly lack any assessment of the consequences of theses
choices on healthy group dynamics.  After all, Apache projects
are all in the recruitment business, and I don’t see how speed
for the sake of speed leads to more activity from newcomers to
the process.  All I see are comments like how great it is that
we are giving users fast turnaround on their bugs, but no mention
of how we are capturing those users attention and converting their
self-interest into project development.



On Feb 10, 2014, at 5:47 PM, jan i <jani@apache.org> wrote:

> On 10 February 2014 23:13, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
>> On Mon, Feb 10, 2014 at 1:54 PM, jan i <jani@apache.org> wrote:
>> 
>>> I strongly believe we (ASF) shall do whatever we can to make sure our
>>> releases are as stable as possible !
>> 
>> Those who advocate scheduled releases and a fast cadence believe that they
>> are
>> doing exactly that.  In fact, the argument goes that bunching up large
>> amounts
>> of changes in each release makes for lower quality.
>> 
>> Who's right, you or them?  Are you so sure of your conclusion that you
>> believe
>> communities which want to follow these practices must be excluded from the
>> ASF
>> because you believe their software will inevitably be low quality?
>> 
> 
> I just made personal observations from my personal experience. I am not the
> one to judge who is right or wrong. And please remark I did not talk about
> excluding projects, that would be very wrong !
> 
> I have worked mainly with international projects with participants from
> many continents (like many of our projects), and maybe that fact is the
> root cause of the problems I have experienced. Having to cope with
> china/europe/US within a 24 hour frame, often lead to the problems I
> described, and I can only assume it must be a lot harder with volunteers.
> 
> I simply tried to suggest a middleway that might be (or might not be)
> acceptable to broader group.
> 
> 
>> This isn't new, or experimental.  It's a major movement in software
>> development, years old, with many popular, successful projects on board.
>> 
> 
>> Marvin Humphrey


Mime
View raw message