Mailing-List: contact dev-help@ignite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <20150727233005.GW30506@boudnik.org>
References: 
 <CA+0=VoX=horv7UqhTFj-e_82qWVdSJXL28g01iCoPhpQ77ma3Q@mail.gmail.com>
	<CAOeZVidAuCRTAOzUKXc03Q44wy6JyheSQPser_ARbuiVP74E-g@mail.gmail.com>
	<55B5DE2B.5040300@apache.org>
	<CA+0=VoVURg-vF39XgfkeKfc98YhABUnF9DBg-KEbc+PmukbdFQ@mail.gmail.com>
	<55B5E066.3080003@apache.org>
	<CAOeZViebY9ER4rMGantU-R7YzV=MO9R2zJwz_bXwmXjYibrftA@mail.gmail.com>
	<55B5E2BB.4030303@apache.org>
	<9F2777E4-9AA2-4FD8-8464-B800B7D09EB5@apache.org>
	<CA+eZwrHL+mwaRnXYHSLrXSR8Fwr-C8PGNRVZexpoR=aBS190Kg@mail.gmail.com>
	<55B6BA2F.2000106@apache.org>
	<20150727233005.GW30506@boudnik.org>
Date: Tue, 28 Jul 2015 14:30:55 +0700
Message-ID: 
 <CALH+G9rN6uUcZEJ4Fx_afEp3fOY_9U2atkC8gBmseMc7N10CnQ@mail.gmail.com>
Subject: Re: Jira Process
From: Alexey Kuznetsov <akuznetsov@gridgain.com>
To: dev@ignite.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11c2750a6543e5051bea73ac

--001a11c2750a6543e5051bea73ac
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In my experience RTC is better.

As I can see Ignite evolving very fast  with this model.
Why some one expects that RTC will slow down development?

I'm for RTC.

On Tue, Jul 28, 2015 at 6:30 AM, Konstantin Boudnik <cos@apache.org> wrote:

> On Tue, Jul 28, 2015 at 01:09AM, Branko =C4=8Cibej wrote:
> > On 27.07.2015 18:29, Sergi Vladykin wrote:
> > > Guys,
> > >
> > > I would say Ignite is quite a big and quite complex project.
> >
> > This has absolutely nothing to do with trusting developers. FWIW,
> > Subversion is also very complex, I'll dare say that its object model an=
d
> > working copy semantics are more convoluted than anything you'll find in
> > Ignite. We make do with CTR quite well.
> >
> >
> > >  Also we have
> > > really tough requirements for performance, stability, backward
> > > compatibility, etc...
> >
> > Write them down. Make sure new contributors understand them before
> > offering them commit access. That's a prerequisite for growing an open
> > community anyway.
> >
> > > Having said that it is really easy to break something
> > > even with minor change like switching type of collection to another
> one.
> >
> > So? Stuff like that should be documented in the code, if it isn't no
> > amount of prior review will help, since how do you know that the
> > reviewer happens to remember such details a few years from now?
> >
> > > And I personally feel safer when my code has been reviewed before I
> merge
> > > it to master.
> >
> > So ask for a review if you think you need it. I never said *all* review=
s
> > should be post-commit: I said that the default mode should be CTR and
> > it's up to the developer to ask for more eyes on their code.
> >
> > > Also when thousand lines change set is merged and there are
> > > conflicting change sets merged after, it is quite hard to rollback th=
is
> > > first change if it was wrong. And we have conflicting changes all the
> time.
> >
> > Apparently you need to learn to use the version control tool you
> > selected, or adjust your workflows for the failings of said tool. Or
> > change the tool, who knows, you might find that's a good move. :)
> >
> > Regardless of which tool you use, conflicts should *ALWAYS* be resolved
> > on the development branch, not on the mainline: the workflow should be:
> >
> >  1. create branch from mainline
> >  2. make changes on branch
> >  3. merge mainline to branch and resolve conflicts (repeat as needed)
> >  4. run tests on branch code
> >  5. merge branch to mainline
> >
> > Skipping step 3 (and 4) is going to be a constant pain regardless of
> > which tool you use. Also for trivial changes it makes no sense at all t=
o
> > even create a branch; just fix it on the mainline, your version history
> > will be a lot easier to follow.
> >
> > > My opinion is that correct trade off for us now is having slower but
> more
> > > predictable development. RTC approach here definitely fits better.
> >
> > RTC has an additional problem that it can (and often does; look at one
> > of the most famous ASF projects if you don't believe me) create tension=
s
> > in the community. It makes sense to use it for maintenance branches, bu=
t
> > not for new development.
>
> Needless to say, I agree with everything just said (except for the VCS
> change
> proposition, which I found to be outright crazy, of course ;)
>
> And to pile more on top: I've experienced the consequences of the very
> situation, described in the very last paragraph. The RTC lead to a totall=
y
> nuts situation in Hadoop, where fellas who wanted to reject a small patch=
,
> not
> based on the technical merits of the fix, had came up with an excuse that
> the
> reviewer (a full committer) didn't have enough expertise to review the
> code in
> question. The silliness was quickly put down by the sane community member=
s,
> but you see where I am going with it...
>
> In other words: if you don't trust a committer to make the changes in the
> VCS
> system - that committer shouldn't be having the commit-bit in the first
> place.
> Intricacies of roll-backs aren't an excuse and most often than not could =
be
> fixed by changing the process hygiene. CTR attitude leads, in general, to=
 a
> higher quality of the contribution because ppl are trying to avoid public
> scolding, inevitable in case of forced-reverts. With RTC the blame would =
be
> shared between the author and the reviewer, which make situation more
> bearable
> (falsely, of course). And guess what - reviewers are humans and make
> mistakes
> all the time, but that was already pointed out.
>
> Cos
>
>


--=20
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

--001a11c2750a6543e5051bea73ac--