Wait, conflict resolution should be done at the dev. branch, not on master.
Also, if your work is properly rebased than rollback becomes a trivial
git revert SHA1
In the current schema of things a rollback might be indeed hard, because
branch merges bring tons of commits like
"Ugh, damn, I forgot to fix the type"
or
"Merge master to my-dev branch"
which are non-informative junk that just pollutes the history and makes
navigation impossible.
Cos
On Mon, Jul 27, 2015 at 07:29PM, Sergi Vladykin wrote:
> 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.
> >
> >
> >
