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