community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: How can we support a faster release cadence?
Date Tue, 11 Feb 2014 15:37:35 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message