Guys, I would say Ignite is quite a big and quite complex project. Also we have really tough requirements for performance, stability, backward compatibility, etc... Having said that it is really easy to break something even with minor change like switching type of collection to another one. And I personally feel safer when my code has been reviewed before I merge it to master. Also when thousand lines change set is merged and there are conflicting change sets merged after, it is quite hard to rollback this first change if it was wrong. And we have conflicting changes all the time. My opinion is that correct trade off for us now is having slower but more predictable development. RTC approach here definitely fits better.
Sergi 2015-07-27 11:01 GMT+03:00 Konstantin Boudnik <c...@apache.org>: > > > On July 27, 2015 12:50:19 AM PDT, "Branko Čibej" <br...@apache.org> wrote: > >On 27.07.2015 09:43, Atri Sharma wrote: > >> On Mon, Jul 27, 2015 at 1:10 PM, Branko Čibej <br...@apache.org> > >wrote: > >> > >>> On 27.07.2015 09:36, Dmitriy Setrakyan wrote: > >>>> On Mon, Jul 27, 2015 at 12:30 AM, Branko Čibej <br...@apache.org> > >wrote: > >>>>> We've all seen problems with bad commits. Bugs happen. If it's > >>>>> accidental, live with it. If it's consistent from some person, > >teach > >>>>> said person to do better. There's no reason to go all paranoid > >over a > >>>>> potential occasional bug in a commit. > >>>>> > >>>>> I mean, it's ridiculous to go all agile with sprints and scrums > >and CI > >>>>> and whatnot, and then block progress because you're afraid to > >trust your > >>>>> fellow developers to not goof off all the time. > >>>>> > >>>> Just as an observation, I don't think RTC process was slowing down > >>> progress > >>>> at Ignite as reviews usually happen pretty fast. > >>> They do now, when the project is fresh and the majority of active > >>> committers are actually not doing this in their spare time. You need > >to > >>> think ahead a bit, too. > >>> > >>> > >> I do see your point but I think you will agree that a pre message on > >> developers list is necessary giving time for potential objections. > > > >The point is that I definitely do not agree with that. Developer > >receive > >commit notifications; that's enough of a nudge to review the commit. > > > >In my experience, prior reviews don't find any more bugs that post > >reviews. This assumes two preconditions: a) Design discussions and > >decisions are made on the dev@ list before a feature or change is made; > >and b) developers request a prior review when they feel it's necessary. > >But it should be up to the developer to make that judgement call. > > Huge +1, really. It's truly in the spirit of trustworthy and healthy > community. > > >
