It concerns me that people are knocking a fast release cadence *without having tried it here*
Q: Is a fast cadence right for every project at ASF? A: I think not Q: Is a fast cadence right for the majority of projects at ASF? A: I suspect not Q: Is a fast cadence wrong for any project at ASF? A: We have no way of knowing until we try... So the important question then becomes how can we try and how does the ASF make it harder to try? In my opinion, individual PMCs are free to experiment with fast cadence releasing, but they should weigh up the potential benefits for their community with the potential risks. A proposal for "tweaking" the voting process in order to support fast cadence releases would (to my mind) have to be presented to the board. Such a proposal would need to show that the PMC has considered the risks and put mitigations in place. Things that, to my mind I would expect, the proposal should include: * Defined process for "short votes", i.e. less than 72h, if the PMC feels they need "short votes". The process would need to define at what point a "short vote" has to revert to the full 72h (my view is if anyone has requested - perhaps in advance - the vote be extended to 72h or if any negative binding vote is cast) * Define any tooling that the PMC is putting in place in order to assist with the board's requirements for casting a binding vote on a release. The tooling should be such that it can be subjected to integrity checks by the PMC. So for example, if a CI job is set up that downloads the release bundle and does "check that the bundle compiles" part on multiple environments, there would need to be a mechanism whereby a PMC member can verify that the results of such a build job were not a tampered "fake" result. * Define a procedure whereby the community can request the cadence be lowered. * Define some key metrics of the community that will indicate whether the community is remaining healthy despite the increased cadence. I am sure there are other things that a proposal should include. I do not think it is difficult to put together a proposal that covers all of the above... in fact I can see from this discussion thread that there is at least the bones of one such proposal in the thread content. If after several experiments we have satisfied ourselves that there is an "established practice of fast cadence releasing at ASF" then I would think that projects could just use that established practice and not have to worry so much about their proposal... though I still feel that they would need to put the proposal before the board as releasing things is something that was delegated to each PMC on the basis of several requirements, so drifting from those requirements as a matter of a weekly/bi-weekly policy should be something that requires board consent. -Stephen On 11 February 2014 15:06, Joseph Schaefer <joe_schae...@yahoo.com> wrote: > +1. Thinking early releases will yield higher quality > confuses cause and effect. The organization Jim describes > is the organization I joined over a decade ago, and still > think the values he expresses are worth hanging onto today. > > On Feb 11, 2014, at 9:37 AM, Jim Jagielski <j...@jagunet.com> wrote: > > > > > On Feb 11, 2014, at 12:51 AM, Marvin Humphrey <mar...@rectangular.com> > wrote: > > > >> On Mon, Feb 10, 2014 at 3:57 PM, Dave Fisher <dave2w...@comcast.net> > wrote: > >>> I have a real example where defined cadence is not as good as the > Apache Way. > >> > >> Apache policy does not forbid releasing on a predictable schedule. > Projects > >> are already free to release quarterly, monthly, or even weekly if they > choose. > >> > > > > That's right. There are lots of little phrases like "Release > > Early and Often" which emphasize that. But one of the nice > > things about Open Source projects is that, well, it's NOT > > work, its NOT a job, and we can also balance having a known > > and reliable release schedule with "We Won't Release Until > > Its Ready". > > > > PMCs aren't factories, churning out releases and code like > > widgets. We do that enough at our day-jobs. PMC and Apache > > projects should be, IMO of course, considered more like > > making a good wine or brewing a fine ale. It's a craft. > > It's an art form. FOSS projects should be fun and safe > > places where you can practice your craft. > > > >
