cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: too long to package a release?
Date Wed, 20 Feb 2013 19:49:15 GMT
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
> >
>

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