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 Mon, 10 Feb 2014 19:52:14 GMT
On Monday, 10 February 2014, Jim Jagielski <jim@jagunet.com> wrote:

> > So, I could ask, what's special about 72 hours?
>
> It was to prevent things from sneaking out during a weekend


So the release vote is scheduled for mid-week so that holiday weekends
won't come into play... Ok you'll have St Patrick's day falling on the
release day every 7 years or so... Same for the 4th of July and other
national holidays but if that affects the vast bulk of the PMC then the PMC
has a diversity problem ;-)


> by a secret cabal when people are otherwise engaged...


I also am assuming that the test suite for a release vote is either good or
slow... If good it will catch problems... If slow then the RC will have
been cut several hours before the vote is called... Further extending the
time for people to register a "fall back to 72h" vote because you can see
the "dodgy" commit of the cabal going in 6h before the release vote so that
the test suite can start on the RC

I don't think you can do fast cadence without tooling support or you will
burn out the PMC and community... So to my mind tooling is a necessary
requirement... These are not a set of isolated independent things... They
are a combination of changes that conspire to find a second local minimum
to the problem set, just a local min that has releases every week

;-)


> Plus,
> again, based on the old adage that people who are involved
> are doing so *as volunteers*, and, as volunteers, there avail
> cycles would ebb and flow, 72 hours was/is a nice compromise
> to allow for semi-quick decisions but still enough time
> so that people didn't consider all this effort as work,
> instead of fun.
>

It can be fun getting your changes released every week and getting feedback
from users...


-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message