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:57:38 GMT
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
> > > >
> > >
> >
>

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