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 20:32:35 GMT
On Monday, 10 February 2014, Joseph Schaefer <joe_schaefer@yahoo.com> wrote:

> Nevertheless there is something to be said for groups
> who do adjourn when they've actually finished something.
> Taking a break is an important part of the typical community
> dynamics.
>
>
Yes, I agree... OTOH if a project *wants* to work that way we should find a
way to let them learn the value of taking a break every now and again ;-)


>
> On Feb 10, 2014, at 2:52 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> > On Monday, 10 February 2014, Jim Jagielski <jim@jagunet.com<javascript:;>>
> 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
>
>

-- 
Sent from my phone

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