Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.185 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 20 Feb 2013 12:01:15 -0800
Subject: Re: too long to package a release?
Thread-Topic: too long to package a release?
Thread-Index: Ac4PpQ4begFZuCTsRweev0Bn0a6Wzg==
Message-ID: <CD4A6B4F.1833D%fil@adobe.com>
In-Reply-To: 
 <CAEeF2TfPu4yJ1STo+54=mO5hE_wLEdy1qbm5mxHMXYD0psbF+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.1.130117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I agree that it is necessary. Just want to make clear that split stream
dev won't speed up the release process (as the thread title implies).

On 2/20/13 11:57 AM, "Michal Mocny" <mmocny@chromium.org> wrote:

>Also: Fil you are totally correct that this flow only really helps with
>split-stream dev, but considering how long it takes and often it happens
>(code freeze due to release) this seems kind of necessary.  I think it is
>also a great foundation for automating packaging and tagging.  So lets
>work
>on that, now.
>
>
>On Wed, Feb 20, 2013 at 2:53 PM, Andrew Grieve <agrieve@chromium.org>
>wrote:
>
>> Fil - looks right to me.
>>
>> Added the git commands for committing into next to the wiki:
>>
>>
>> git checkout next
>> git pull apache
>> git checkout topic_branch
>> git rebase next -i
>> git checkout next
>> git merge --ff-only topic_branch
>> git push apache next
>> git branch -d topic_branch
>> git checkout master
>> git merge next
>> git push apache master
>>
>>
>>
>> On Wed, Feb 20, 2013 at 2:49 PM, Michal Mocny <mmocny@chromium.org>
>>wrote:
>>
>> > Shaz sums it up perfect.  Once we cut 'next' nothing goes in unless
>>its
>> > critical to it being a good release.  Anything that goes into next
>>should
>> > almost by definition also go in to master.
>> >
>> > Note that this is functionally the same as only ever pushing to
>>master,
>> and
>> > cherry-picking certain commits into 'next'.
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Feb 20, 2013 at 2:34 PM, Shazron <shazron@gmail.com> wrote:
>> >
>> > >  http://cl.ly/MOrD
>> > > Master always has all the changes. Next will never have experimental
>> > > changes/features after next is created, just bug fixes.
>> > >
>> > > On Wednesday, February 20, 2013, Joe Bowser wrote:
>> > >
>> > > > Honestly, this process is too complex and we should just go back
>>to
>> > > > what we were doing before.  I don't think our git flow was what is
>> > > > slowing us down.
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj <fil@adobe.com> wrote:
>> > > > > Ok so the flow is: if you are committing into next, always merge
>> into
>> > > > > master. Good. So the CI setup doesn't need to differentiate
>>between
>> > > > master
>> > > > > and next. It can always pull from master.
>> > > > >
>> > > > > On 2/20/13 11:04 AM, "Andrew Grieve" <agrieve@chromium.org>
>>wrote:
>> > > > >
>> > > > >>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>> > > > >>
>> > > > >>Probably it should be "isFixingRegression" instead of
>>"isBugFix".
>> > I'll
>> > > > >>update it now.
>> > > > >>
>> > > > >>
>> > > > >>On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj <fil@adobe.com>
>>wrote:
>> > > > >>
>> > > > >>> I noticed on iOS the commits going into next are mirrored on
>> > master.
>> > > > >>>
>> > > > >>> For Android that was not done.
>> > > > >>>
>> > > > >>> What is the correct process?
>> > > > >>>
>> > > > >>> On 2/20/13 10:12 AM, "Michal Mocny" <mmocny@chromium.org>
>>wrote:
>> > > > >>>
>> > > > >>> >oooo I didn't know that.  Thanks!
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>> > > > >>> ><gibson.becky@gmail.com>wrote:
>> > > > >>> >
>> > > > >>> >> Thank you, Michael!  I do usually go a git push --dry-run
>>to
>> > check
>> > > > >>>that
>> > > > >>> >>I
>> > > > >>> >> am pushing what I expect but I'll try the diff as well.
>> > > > >>> >>
>> > > > >>> >>
>> > > > >>> >> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny <
>> > > mmocny@chromium.org>
>> > > > >>> >>wrote:
>> > > > >>> >>
>> > > > >>> >> > So there is also
>> > http://wiki.apache.org/cordova/CuttingReleases
>> > > > >>>which
>> > > > >>> >> may
>> > > > >>> >> > be useful (esp Taggin section).
>> > > > >>> >> >
>> > > > >>> >> > As far as the confusion with the two branch names:
>> > > "topic_branch"
>> > > > >>>is
>> > > > >>> >>your
>> > > > >>> >> > local working branch for a bugfix/feature, and
>> "to_be_merged"
>> > is
>> > > > >>> >>really
>> > > > >>> >> > "temporary_new_name_for_a_branch_to_do_rebase_in".  I
>> usually
>> > > skip
>> > > > >>> >>that
>> > > > >>> >> > step and take the risk or rebasing in topic_branch
>>(aside:
>> > this
>> > > > may
>> > > > >>> >> > negatively affect diffs if you push updates for a
>> > > > >>> >>review-edit-re-review
>> > > > >>> >> > cycle -- but this isn't an issue for cordova).
>> > > > >>> >> >
>> > > > >>> >> > Do not checkout 'next' into your master branch.  Update
>>your
>> > > local
>> > > > >>> >> branches
>> > > > >>> >> > to include the remote next branch (with 'git pull apache'
>> with
>> > > no
>> > > > >>> >>branch)
>> > > > >>> >> > then you can switch to the next branch locally, apply
>>your
>> > patch
>> > > > >>> >>there,
>> > > > >>> >> and
>> > > > >>> >> > push to that remote branch directly.  Later, merge that
>> commit
>> > > > into
>> > > > >>> >> master
>> > > > >>> >> > locally, and push that.
>> > > > >>> >> >
>> > > > >>> >> > Do not push to apache next from your local master, or
>>else
>> you
>> > > > will
>> > > > >>> >>push
>> > > > >>> >> > all the changes.
>> > > > >>> >> >
>> > > > >>> >> > I agree, this is a little confusing, but after a few
>> practice
>> > > runs
>> > > > >>>it
>> > > > >>> >> > should be easy to figure out.  You should probably also
>> check
>> > > what
>> > > > >>> >>would
>> > > > >>> >> be
>> > > > >>> >> > pushed with 'git diff apache/[target-branch]' or tag on
>> --stat
>> > > to
>> > > > >>> >>that to
>> > > > >>> >> > just see that files that would signal a quick "uh-oh".
>> > > > >>> >> >
>> > > > >>> >> > I'll work to update the wiki later today, and likely
>>others
>> > will
>> > > > >>>have
>> > > >
>> > >
>> >
>>