accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: Backporting policy proposal
Date Tue, 18 Jun 2013 15:31:07 GMT
There are flow issues though, especially when you get into the realm of
rebasing, etc. So, like SVN, there should be one established direction.


On Tue, Jun 18, 2013 at 11:26 AM, Adam Fuchs <afuchs@apache.org> wrote:

> On Jun 18, 2013 11:05 AM, "Josh Elser" <josh.elser@gmail.com> wrote:
> >
> > On 6/18/13 10:53 AM, Adam Fuchs wrote:
> >>>
> >>> >
> >>> >2. Back-porting performance improvements to a prior release line that
> >>> >is not EOL (end-of-life) is usually okay (subject to normal lazy
> >>> >consensus), so long as it does not change user-facing behavior or API.
> >>> >It is still strongly preferred to add such fixes in the older branch
> >>> >first, and merge forward to the newer one(s).
> >>
> >> Agree, although doesn't the transition to git alleviate the problems
> with
> >> order of operations?
> >>
> >
> > I don't understand what you mean by "order of operations". If you push a
> commit in 1.6.0-SNAPSHOT that should really be in 1.4.4-SNAPSHOT, Git will
> not handle this well in terms of an accurate history.
>
> I don't really understand either -- that was mostly speculation. Doesn't
> the reliance on hashes of the patch rather than commit IDs make it
> immaterial as to which branch a patch was committed to first? Admitedly, I
> am not an expert on git.
>
> Adam
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message