On Mon, Jul 27, 2015 at 12:42 PM, Dmitriy Setrakyan <dsetrak...@apache.org> 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? Also, what happens if an occasional bad commit sneaked into the > release branch? > > As someone who has seen problems with bad commits, I totally second Dmitriy. Developer bugs be better caught and prevented rather than backpatched and fixed. > > > Please don't go all control-freak on the source: it should be more than > > enough to have a working CI, perform post-commit reviews and to run > > tests on releases. > > > > Not trying to... I was merely describing the dev process as of today. > However, I am not seeing how a post-commit review speeds up the process. > The review still occurs regardless, so why not do a pre-commit review to be > safer? > Unless its a critical patch, I totally agree with Dmitriy here.
