So I am thinking that we have gotten into this habit of holding onto changes in core far far too long.
I think it might *help* the community if we tried to move releases out faster. The idea would be that we set up a set of conditions for a release, e.g. * If there are no changes to the 3.2.x branch since the last release (and at least _X_h since the notification landed on the commits list - see voting below for the _X_ value) then there will be no release, otherwise those changes are the scope of the potential candidate. * If the potential candidate passes all integration tests, then the release manager will cut the release candidate based on the potential candidate. We would cut releases on a defined day in the week. The version number will not be reused. * There would be a vote to release the release candidate. For now we will say that the standard 72h voting rules will apply, but we may put a proposal before the board to define a set of conditions whereby the voting period can be shorter, i.e. (72-_X_)h unless there is an absence of consensus. * If there are any issues with the release candidate, we drop it on the floor and forget about it, no respinning. Repeat the above every week. I would propose an 3 month experiment with the above process (starting once we get the first 3.2.x release out) There are some open issues I can think of: 1. How do we pick the release manager 2. Will there be PMC fatigue in voting on releases Thoughts anyone? -Stephen
