Hi -- > As an example -- based on how a project like httpd works -- let's say > we've just released 1.0.0 and created the 1.0.x branch. Now a patch > goes into trunk that doesn't change the API/ABI. That can be proposed > as a backport in the 1.0.x STATUS file, and if it gets three +1 votes > (and no -1 votes, IIRC), it can be committed to 1.0.x.
I should have explained that all of this relates to the key difference between the principles of CTR and RTC. In the APR and httpd projects, the CTR principle applies to trunk, that is, "Commit, Then Review". So any committer can commit to trunk at any time; if it's a substantial change or security fix, they should describe it in the CHANGES file, but otherwise there's nothing special to do. (Obviously major revisions should probably be discussed on the mailing list first.) The branches, which are expected to be stable, are governed by the RTC principle: "Review, Then Commit". Hence all the stuff about proposing backports, getting votes, etc. For more, see: http://www.apache.org/foundation/glossary.html#CommitThenReview http://www.apache.org/foundation/glossary.html#ReviewThenCommit Now, as far as I know, there's nothing that says all projects must adopt these particular rules. For a younger project like Axis2/C, it would make some sense to me if the project's developers and its PMC decided to adopt CTR for the branches well, perhaps with some further clarifications. For example, maybe vetoes (for CTR, a veto means a rollback of a change) can be made by any committer to any change in a branch. If no tagged versions have been made since the change was introduced to the branch, then there's nothing else to do, but if a tagged version has been made, then the person performing the veto/rollback needs to be in charge of organizing a new tagged version of the branch as soon as possible. (This is on the theory that, if you're undoing something for some reason, you probably want to get the reverted code out to end users immediately.) Anyway, that's just a passing thought -- it might not be appropriate. I'd think it's probably worth dicussing these issues at the PMC level, now that we've got a stable branch to maintain. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
