community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 21:54:49 GMT
On 10 February 2014 22:26, Jim Jagielski <> wrote:

> On Feb 10, 2014, at 2:52 PM, Stephen Connolly <
>> wrote:
> >
> > It can be fun getting your changes released every week and getting
> feedback
> > from users...
> Again, look at this from the PoV of a truly volunteer
> contributor... If he/she needs to constantly watch the
> list to make sure that they are able to vote on a release,
> it becomes a job, a task, rather than fun.

I think I am one of the "truly volunteer contributors". For me a 12 hour
window would be very hard to meet even in my own TZ.

If you are part of multiple projects and have a real life, more than 12
hours are needed to do what we as PMC need to do.

I have read this thread with great interest, because I had fast release
cycles in my day-job and dropped it, because it actually lead to less
stable software:
- developers did not care so much (motto, we can always make it better next
- testers did not care so much (motto: we dont have time to really test the
- users complained that they could not install versions as fast as we
delivered them.

I strongly believe we (ASF) shall do whatever we can to make sure our
releases are as stable as possible ! The release procedures we have,
compared to a lot of other openSource projects, was a significant reason
for me joining ASF.

One way to get around the problem set, is to use a combination of releases
and patches.

E.g. have a release every quarter, which runs through the normal cycle, and
are marked as an official release. Second make a patch every week. A patch
is a lot like a snapshot, but automatically tested and controlled by
several PMC. The naming difference is important so users know what they get.

Just some thoughts from a "junior" committer.

jan I.

> How "welcoming" would a project be for you to join, for
> fun, if it *required* you keep track of it as if it was
> your job?
> In addition to nurturing the present community, you
> also need to nurture the future community.

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