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" <mmo...@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 <agri...@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 <mmo...@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 <shaz...@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 <f...@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" <agri...@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 <f...@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" <mmo...@chromium.org> >>wrote: >> > > > >>> >> > > > >>> >oooo I didn't know that. Thanks! >> > > > >>> > >> > > > >>> > >> > > > >>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson >> > > > >>> ><gibson.be...@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 < >> > > mmo...@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 >> > > > >> > > >> > >>
