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 > > > > > >
