Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.220.41 as permitted sender)
From: Phil Steitz <phil.steitz@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Understanding the commit-then-review workflow
Message-Id: <B2498629-E6FE-40E3-BE5B-E2BE4E875EC8@gmail.com>
Date: Tue, 8 Jul 2014 18:05:10 -0700
References: 
 <CAMkzgA6EHywVSrOg40Brv=sqGsFft8awXJj9q6wsrcRsi4GXYQ@mail.gmail.com>
 <B03D7BB2-731A-4F26-89D9-ADA37BE33F6E@jaguNET.com>
In-Reply-To: <B03D7BB2-731A-4F26-89D9-ADA37BE33F6E@jaguNET.com>
To: "dev@community.apache.org" <dev@community.apache.org>


> On Jul 8, 2014, at 3:17 PM, Jim Jagielski <jim@jaguNET.com> wrote:
>=20
> The idea of CTR is that the repo that the commit is made
> to is not in the direct path to a release. Thus, one
> can commit to the repo/branch as a sort of shared sandbox.

Not necessarily.  Some projects do CTR right up to release tags.

Phil


>=20
> When a commit is proposed to enter into the release
> path, that path is RTC, which means that the patch
> must be proposed as a backport, and that before that
> backport commit can happen (eg, via svn merge), that
> the patch must be reviewed and voted on in that
> path (and on the mailing list specific to that path,
> if one exist).
>=20
> Key in the below is how "dislike" is defined. If, for example,
> I don't like using a while() loop instead of a for() loop,
> I can either patch the code myself (since we are CTR) or
> offer suggestions on why the change should be made, etc...
> I cannot, however, veto the entire patch/commit for personal,
> non-technical reasons.
>=20
> Now all this works only when developers are actively
> working *together* as a group, and that consensus building
> is a main factor in that development. That is why the
> *behavior* around git (not git itself) is somewhat circumspect
> @ Apache, since it really reinforces the idea that instead
> of it being a group of people working on the same codebase,
> each person is individually working on their own fork of
> the codebase and, eventually, some stuff gets shared. In
> that mindset, each patch/commit is seen as "personal" and
> not "communal", if you get my drift.
>=20
>> On Jul 8, 2014, at 3:24 PM, Eric Schultz <eschultz@prplfoundation.org> wr=
ote:
>>=20
>> All,
>>=20
>> I'm trying to understand to the Apache Foundation model of voting in the
>> commit-then-review system. If a project is running on a CTR system and
>> someone says they dislike a piece of a previous commit, what happens? Doe=
s
>> it require consensus to remove the code or is the code removed if consens=
us
>> isn't reached to keep it in?
>>=20
>> Thanks,
>>=20
>> Eric
>>=20
>> --=20
>> Eric Schultz, Community Manager, prpl Foundation
>> http://www.prplfoundation.org
>> eschultz@prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>=20