On 10 February 2014 22:26, Jim Jagielski <j...@jagunet.com> wrote: > > On Feb 10, 2014, at 2:52 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> 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 week) - testers did not care so much (motto: we dont have time to really test the release) - 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. rgds 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.
