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 shazron@gmail.com designates
 209.85.128.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOBL_k5f12dLLsrBa1hQGUGBAtY6bUhsMU9bGWmO3=WR0bLTVA@mail.gmail.com>
References: 
 <CABiQX1XVmNJNfz=Y3RJ-WcmdQdypJLnH9gOviSxrKuMm7F2P6g@mail.gmail.com>
	<CD4A6210.18305%fil@adobe.com>
	<CAOBL_k5f12dLLsrBa1hQGUGBAtY6bUhsMU9bGWmO3=WR0bLTVA@mail.gmail.com>
Date: Wed, 20 Feb 2013 11:34:12 -0800
Message-ID: 
 <CAE6O_-Zk_3mRm0w0Ym+xHxD0B6+o1hoUHwcfGRnUAWYLyKO1=Q@mail.gmail.com>
Subject: Re: too long to package a release?
From: Shazron <shazron@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf3074d574fde71304d62d0a18

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

 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
>

--20cf3074d574fde71304d62d0a18--