cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: too long to package a release?
Date Wed, 20 Feb 2013 19:34:12 GMT
 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
>

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