Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.219.47 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k51HAhodVgMOB02uDCLtGr+MKnRHdP2q9MM5t5oioibeg@mail.gmail.com>
References: 
 <CAOBL_k6cdWZit6EtHRoDrak8kcjNKQkECEDNSigcNX0kmdi49A@mail.gmail.com>
 <CD50F083.1882B%fil@adobe.com>
 <CAOBL_k4ZHqTg4vYs1=LDastRy9=QJOqHbfwasKg2W8A-GjmX3A@mail.gmail.com>
 <CABiQX1Xi_RYRH7mFxtNK4yV=AT3Kcyt97VpK_pSUKuKH31WEdw@mail.gmail.com>
 <CAOBL_k51HAhodVgMOB02uDCLtGr+MKnRHdP2q9MM5t5oioibeg@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Mon, 25 Feb 2013 15:59:25 -0500
Message-ID: 
 <CABiQX1XeVd2C4592t_QTPWE3HuN6VBt5TTVNdis7wv_=JBN51A@mail.gmail.com>
Subject: Re: Jasmine Tests failing with the most recent multipart changes
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=e89a8fb2055a23506404d692d240

--e89a8fb2055a23506404d692d240
Content-Type: text/plain; charset=ISO-8859-1

Do the changes you'd like to see cherry-picked fix regressions? If not,
then I'd say just leave them broken in 2.5.

I think what'd you'd do then is cherry-pick into next, and then immediately
merge next into master. The merge in this case should have a conflict
because of the two identical changes, but it should be able to auto-resolve
them.

So far, I've been finding this workflow much better for having forward
progress. Since we created the next branch, we've have 17
non-regression-fixing commits to cordova-ios. In our old flow, this number
would be 0.

I am also finding that having to figure out if I want to commit to next vs
master *before* I make a change to be taxing though. The reason we're doing
it this way around is so that we can use the same release branch "next" for
the next release as well. If we used named branched (e.g. "next2.5.0") then
we could commit to master and cherry-pick after-the-fact the changes we
want in the release branch.

Let's maybe discuss our options here after this release is over with.


On Mon, Feb 25, 2013 at 3:10 PM, Joe Bowser <bowserj@gmail.com> wrote:

> I haven't cherry-picked anything into next yet.  I've kept working on
> master and I've been ignoring next.  However, there's some things in
> master that I would like to see in the next release.  How do we do
> that without cherry-picking? Or do we just keep things broken in 2.5
> and just shrug our shoulders and say whoops?
>
> Again, I think this work-flow is terrible, and I would like to go back
> to what we used to do if cherry-picking really breaks things this bad.
>
> On Mon, Feb 25, 2013 at 12:01 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> > Joe - do you mean you're committing to master and cherry-picking into
> next?
> >
> > I think this would result in two identical-but-different changes
> appearing
> > in the two branches, whereas checking into next and merging into master
> > ends up with the same change appearing in both branches. The result of
> this
> > (I think) is that cherry-picking will make history a bit more confusing,
> > and increase the risk of future merges having conflicts.
> >
> >
> > On Mon, Feb 25, 2013 at 1:52 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> >> That's assuming that we're fixing for release.  I've been doing all
> >> work in master at this point. I think we're fine doing both
> >> cherrypicks and merging, but I think that's what makes this process
> >> complicated.
> >>
> >> On Mon, Feb 25, 2013 at 10:42 AM, Filip Maj <fil@adobe.com> wrote:
> >> >
> >> >>Also, on a side note, for the release, if there's commits in master
> >> >>that we want in this release, do we do a cherry pick into next?
> >> >
> >> > Yes. I see it the opposite way (I commit into next and merge into
> >> master).
> >> >
> >>
>

--e89a8fb2055a23506404d692d240--