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 <j...@apache.org> wrote: > On 10 February 2014 23:13, Marvin Humphrey <mar...@rectangular.com> wrote: > >> On Mon, Feb 10, 2014 at 1:54 PM, jan i <j...@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
