Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.213.181 as permitted sender)
Message-ID: <51B7C4DB.5030104@gmail.com>
Date: Tue, 11 Jun 2013 20:46:19 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130610 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [git] Documentation and Plan of Action
References: <51AEAAD0.9020902@gmail.com> <51AFECB5.9010901@gmail.com>
 <51B68F00.6020904@gmail.com>
 <CAGHyZ6KYgEqSiSb4FHf0qz42-pszoM-HMA4fuEvUnUpxrwY3ww@mail.gmail.com>
 <51B71E58.6010702@gmail.com>
 <CAJRvFdpkuu=cGyJfWiM7_oemtM-mSVVDBL0ODHH_zF8D1EcntA@mail.gmail.com>
 <51B74AAE.6030400@gmail.com>
 <CAL5zq9birQMP27u92PnhDxFNtZa9ZL1bLQXoi1xsrESS7Zum8A@mail.gmail.com>
In-Reply-To: 
 <CAL5zq9birQMP27u92PnhDxFNtZa9ZL1bLQXoi1xsrESS7Zum8A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 06/11/2013 12:26 PM, Christopher wrote:
> On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>> >The person who implements the workaround in Version1 should ensure that when
>> >Version1 is merged into Version2, the correct code is present in Version2.
> I'm not sure that's a sufficient solution, because this means that the
> branch for Version2 may stick around with effectively no change from
> its last tag other than history, and you can't simply update the tag
> to update the history, can you? Either it sticks around for a very
> long time, or it goes away and eventually somebody else is going to
> have to resolve that potential merge conflict when fixing the next bug
> that comes around (which maybe applies to both).
>

I think I already addressed this concern with Mike later in this thread, 
but I'll restate for completeness:

Even if a merge from v1 to v2 is a no-op in terms of changes, the fact 
that a non-no-op change in v1 merits a no-op change in v2 is important, 
and thus this is important for the developer to record with a merge.

The lifetime of the v2 branch is then subject to the same circumstance 
we've talked about previously.