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 Tue, 11 Feb 2014 15:56:13 GMT
The core question for me is do we want to continue
down this path of attempting to be all things to
all people with no common culture or values or processes,
or is there a floor somewhere.  If there is, where
should it be?

I don’t expect you to answer that question but that’s
what’s bothering me about this whole exercise.  Typically
I try to be open minded about new things and local
experimentation, provided it’s sustainable and self-
managing.

The release policy rationale amendments I wrote leave the door
open for proposals of this nature to be entertained
by the board.  Had I been tasked with writing that section
of the policy three weeks ago, that option would have
been left out entirely and it would be FORBIDDEN to
deviate from the document.  So take that for what it’s
worth.


On Feb 11, 2014, at 10:37 AM, Stephen Connolly <stephen.alan.connolly@gmail.com> wrote:

> 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_schaefer@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 <jim@jaguNET.com> wrote:
>> 
>>> 
>>> On Feb 11, 2014, at 12:51 AM, Marvin Humphrey <marvin@rectangular.com>
>> wrote:
>>> 
>>>> On Mon, Feb 10, 2014 at 3:57 PM, Dave Fisher <dave2wave@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.
>>> 
>> 
>> 


Mime
View raw message