All I'm looking for is some evidence that tweaking the nobs and dials on release process has been done successfully in a project that has values similar to Apache projects.
I'm still in a mild state of shock about how we find ourselves having this conversation about a fifteen year old policy that I assumed was a cornerstone of the social contract our projects have with their participants. Even if we expanded the build farm budget ten fold it can't match the production resources a vibrant community can throw at a release candidate, but losing people who can do things like that is seemingly the price of progress. Sent from my iPhone > On Feb 10, 2014, at 11:21 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> On 2/10/14, 3:05 PM, Joseph Schaefer wrote: >> 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. > > That is an interesting question that would be tricky but possible to > look at empirically - how does release frequency correlate with user > engagement? The tricky bit is how to measure user engagement. Not > just list traffic / JIRAs, but sustained contribution from users of > the software. In projects dominated by paid developers it might be > hard to identify and track users coming into the community. I > wonder if anyone has tried to do this. > > Phil >> >> >> >>> 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 >
