Martin Sebor wrote:
After Feature Freeze, our release process says that only the RM does merges. Unless the RM wants to merge each change individually the multi-change format is the only one that makes sense.
Just want to point out or clarify a few things... multichange commits become much harder to follow, therefore they may be an obstacle to devs during a release vote. But either way, what you describe above is the process most ASF projects apply to one release. So let's say for a moment that Travis wants a release, and you want a release, and have different goals. Both branch, patch and tag, and the community votes on which release is right. It's a really obscure way to an end point (one release that the project agrees to), but it ensures a project's never hostage to only-one-way to get things done. It's an example of why a release can't be vetoed. But I want to clarify, no one individual ever has sole commit authority over a maintenance branch, period. I know this came up during incubation, but the policy is very harsh. The ASF is not about individual PMC members, not even the chairman, but it's a flat meritocracy. So the code is either C-T-R with every committer having direct-access, or R-T-C with every committer proposing patches, and a community vote (not one person's decision) over the patches that are applied. I'm a bit concerned, what with RW's generous test and build mechanics, etc, that the project does appear more homogeneous than even at the point it graduated (incubation is not the end of the diversity and broader community requirements). I've noticed about 3 or 4 posts a month which read as entirely partisan/commercial, and I'd appreciate if everyone would keep their eyes out for such problems. Bill
