On 27.07.2015 09:12, Dmitriy Setrakyan wrote: > On Sun, Jul 26, 2015 at 11:57 PM, Branko Čibej <br...@apache.org> wrote: > >> On 27.07.2015 08:49, Atri Sharma wrote: >>> I totally agree on this one. >>> >>> In PostgreSQL, every committer's major changes are normally reviewed by >>> somebody else before the committer pushes the patch. However, for trivial >>> patches, committer normally puts post on developer list stating his >> changes >>> and gives a timeline by which he/she will commit patch and objections >> need >>> to come before that. Giving a day for such patches should be fine, IMO. >> Well, over at Subversion, we regularly make major changes on trunk >> without previous review. Our only requirement is that trunk remains >> "stable", i.e., that tests pass; even then, no-one is expected to run >> tests on all supported platforms. Review happens after commit. Sure that >> means occasional bugs creep in, but that would happen regardless. >> >> If we imposed RTC, development of Subversion would literally grind to a >> stop. Developers are volunteers, so they review when they have time, >> which sometimes means a week or more after the actual commit. >> >> Note that for backports to stable release branches, we do have an RTC >> process in place. >> > Can you describe at which point a master becomes a release branch in > Subversion?
http://subversion.apache.org/docs/community-guide/releasing.html > Also, what happens if an occasional bad commit sneaked into the release > branch? It's almost impossible for that to happen, as per the process described on that page. But if it does, we just revert it and try again, usually after creating or fixing a backport branch. -- Brane
