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 >>> >> more >>> >> > tips on how to make sure we don't make mistakes. >>> >> > >>> >> > -Michal >>> >> > >>> >> > >>> >> > >>> >> > On Wed, Feb 20, 2013 at 12:42 PM, Becky Gibson < >>> gibson.be...@gmail.com >>> >> > >wrote: >>> >> > >>> >> > > Can someone please provide a "git cordova release process for >>> >>dummies" >>> >> > > example to make sure I do the release commits and merges properly >>> >>(the >>> >> > > committerWorkflow example didn't help me as I didn't understand >>>the >>> >> > > topic_branch and to_be_merged distinction) >>> >> > > >>> >> > > At any rate, can I do a git checkout apache next into my "master" >>> >> branch? >>> >> > > Then I can checkout my working_branch, rebase master (which >>> >>contains >>> >> > the >>> >> > > next code) checkout master, merge my fix and push apache next. >>> >> > > git checkout apache next >>> >> > > git checkout working_branch_with_fix >>> >> > > git rebase master >>> >> > > git checkout master >>> >> > > git merge working_branch_with_fix >>> >> > > git push apache next >>> >> > > >>> >> > > and then repeat this for apache master with the possibility of >>> >>needing >>> >> to >>> >> > > use -ff when I merge. Am I on the right track? >>> >> > > >>> >> > > humbled by git, >>> >> > > -becky >>> >> > > >>> >> > > On Fri, Feb 8, 2013 at 5:22 PM, Marcel Kinard >>><cmarc...@gmail.com> >>> >> > wrote: >>> >> > > >>> >> > > > Nice! Thanks, Andrew! >>> >> > > > >>> >> > > > -- Marcel Kinard >>> >> > > > >>> >> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve >>><agri...@chromium.org> >>> >> > wrote: >>> >> > > > >>> >> > > > > The doc's not up-to-date, but I think we ended on consensus >>>for >>> >>the >>> >> > > code >>> >> > > > > version. I've taken a stab at updating the wiki pages: >>> >> > > > > >>> >> > > > > http://wiki.apache.org/cordova/CordovaAndGit -- Added the >>>idea >>> >>of >>> >> > > > having >>> >> > > > > both a master and a next branch >>> >> > > > > http://wiki.apache.org/cordova/CommitterWorkflow -- Added >>> >>Jesse's >>> >> > > > version >>> >> > > > > of the "which branch - in code" >>> >> > > > > http://wiki.apache.org/cordova/CuttingReleases -- Changed >>> >>tagging >>> >> > > > > instructions to refer to the "next" branch >>> >> > > > > >>> >> > > > > >>> >> > > > > On Thu, Feb 7, 2013 at 1:26 PM, Marcel Kinard >>> >><cmarc...@gmail.com> >>> >> > > > wrote: >>> >> > > > > >>> >> > > > >> With 2.5 starting, it appears time to poke this thread. >>> >> > > > >> >>> >> > > > >> - Is the Google doc refreshed with the latest consensus? >>> >> > > > >> - If so, should the Google doc be transferred to a wiki >>>page? >>> >> > > > >> - Have the necessary branches been created? >>> >> > > > >> - Are we all in the boat, and understand how to row this >>>beast? >>> >> > > > >> >>> >> > > > >> -- Marcel Kinard >>> >> > > > >> >>> >> > > > >> On Jan 24, 2013, at 5:14 PM, Jesse <purplecabb...@gmail.com> >>> >> wrote: >>> >> > > > >> >>> >> > > > >>> Nice Shaz, but I was hoping it was a github style network >>> >> > > visualization >>> >> > > > >>> that included a few versions worth of merges. >>> >> > > > >>> Who wants to draw that? >>> >> > > > >>> >>> >> > > > >>> On Thu, Jan 24, 2013 at 2:05 PM, Shazron >>><shaz...@gmail.com> >>> >> > wrote: >>> >> > > > >>> >>> >> > > > >>>> Inline image got mangled, here it is linked: >>> >>http://cl.ly/MOrD >>> >> > > > >>>> >>> >> > > > >>>> >>> >> > > > >>>> On Thu, Jan 24, 2013 at 1:39 PM, Shazron >>><shaz...@gmail.com> >>> >> > wrote: >>> >> > > > >>>> >>> >> > > > >>>>> Thanks for the pseudocode Andrew, seems simpler to >>> >>understand >>> >> ;) >>> >> > > > >> Jesse's >>> >> > > > >>>>> re-factor makes it even easier. Here's my contrib for >>>those >>> >> more >>> >> > > > >> visually >>> >> > > > >>>>> inclined: >>> >> > > > >>>>> >>> >> > > > >>>>> >>> >> > > > >>>>> [image: Inline image 2] >>> >> > > > >>>>> >>> >> > > > >>>>> >>> >> > > > >>>>> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve < >>> >> > > agri...@chromium.org >>> >> > > > >>> wrote: >>> >> > > > >>>>> >>> >> > > > >>>>>> Nice! even simpler. :) >>> >> > > > >>>>>> >>> >> > > > >>>>>> >>> >> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse < >>> >> purplecabb...@gmail.com >>> >> > > >>> >> > > > >> wrote: >>> >> > > > >>>>>> >>> >> > > > >>>>>>> Thanks for clarifying Andrew. et al, I guess I was >>> >> > > > mis-understanding >>> >> > > > >>>>>> some >>> >> > > > >>>>>>> of the earlier discussion around naming stuff. >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> So everything is going to master all the time, and we >>>only >>> >> care >>> >> > > > about >>> >> > > > >>>>>>> 'next' if we are inReleaseMode and it is a bug fix? >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> if(inReleaseMode && isBugFix) { >>> >> > > > >>>>>>> commitToBranch('next'); >>> >> > > > >>>>>>> mergeBranch('next').into('master'); >>> >> > > > >>>>>>> } >>> >> > > > >>>>>>> else { >>> >> > > > >>>>>>> commitToBranch('master'); >>> >> > > > >>>>>>> } >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve < >>> >> > > > >> agri...@chromium.org >>> >> > > > >>>>>>>> wrote: >>> >> > > > >>>>>>> >>> >> > > > >>>>>>>> Just to clarify - there should be *no* using of the >>>git >>> >> > > > >>>>>> cherry-picking >>> >> > > > >>>>>>>> command, only git merge. >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>> Jesse - not sure what you're referring to with "branch >>> >>must >>> >> be >>> >> > > > named >>> >> > > > >>>>>> x". >>> >> > > > >>>>>>>> The latest revision of the proposal has only two >>> >>branches: >>> >> > > master >>> >> > > > >> and >>> >> > > > >>>>>>> next. >>> >> > > > >>>>>>>> Do you mean you don't like the name "next"? >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>> Maybe the proposal will seem simpler if put in the >>>form >>> >>of >>> >> > code >>> >> > > :) >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>> if (!inReleaseMode) { >>> >> > > > >>>>>>>> commitToBranch('master'); >>> >> > > > >>>>>>>> } else { >>> >> > > > >>>>>>>> if (isBugFix) { >>> >> > > > >>>>>>>> commitToBranch('next'); >>> >> > > > >>>>>>>> mergeBranch('next').into('master'); >>> >> > > > >>>>>>>> } else { >>> >> > > > >>>>>>>> commitToBranch('master'); >>> >> > > > >>>>>>>> } >>> >> > > > >>>>>>>> } >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>> On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson < >>> >> > > > >>>>>> bra...@chromium.org >>> >> > > > >>>>>>>>> wrote: >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>>>> Most of the time the flow will be unchanged: push to >>> >> master. >>> >> > > > >>>>>> Tagging >>> >> > > > >>>>>>>> things >>> >> > > > >>>>>>>>> we already know how to do; that doesn't change. >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>>> The only new flow for most people is cherrypicking >>>bug >>> >> fixes >>> >> > > from >>> >> > > > >>>>>>> master >>> >> > > > >>>>>>>> to >>> >> > > > >>>>>>>>> next, which we can give examples of. Plus that could >>> >>remain >>> >> > the >>> >> > > > >>>>>>>>> responsibility of the main platform maintainers, who >>>are >>> >> > doing >>> >> > > > the >>> >> > > > >>>>>>>> tagging. >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>>> Braden >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>>> On Thu, Jan 24, 2013 at 2:56 PM, Jesse < >>> >> > > purplecabb...@gmail.com> >>> >> > > > >>>>>>> wrote: >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden >>>Shepherdson < >>> >> > > > >>>>>>>>> bra...@chromium.org >>> >> > > > >>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>>> The founding goal we're trying to accomplish here >>>is >>> >>that >>> >> > we >>> >> > > > >>>>>> don't >>> >> > > > >>>>>>>> want >>> >> > > > >>>>>>>>>>> everyone sitting on changes to be in the next >>>version >>> >> while >>> >> > > we >>> >> > > > >>>>>> use >>> >> > > > >>>>>>>>> master >>> >> > > > >>>>>>>>>>> to prep a release. >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>>> I don't think having one branch for prepping the >>> >>release >>> >> > and >>> >> > > > >>>>>>> another >>> >> > > > >>>>>>>>> for >>> >> > > > >>>>>>>>>>> main development is a lot of bureaucracy. >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>> It is not, the 'branch must be named x' is mainly >>> >>where I >>> >> > have >>> >> > > > >>>>>>>> concerns. >>> >> > > > >>>>>>>>>> Really I just want things simple. >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>>> On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen < >>> >> > > > >>>>>>>>>> purplecabb...@gmail.com >>> >> > > > >>>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> I have been quietly listening on this thread, but >>> >> thought >>> >> > I >>> >> > > > >>>>>>> should >>> >> > > > >>>>>>>> at >>> >> > > > >>>>>>>>>>>> least share my opinion. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> I don't think adding contribution rules helps >>>anyone. >>> >> Git >>> >> > is >>> >> > > > >>>>>>>>>>>> complicated enough as it is, and this just all >>>seems >>> >> like >>> >> > > > >>>>>>>>> bureaucracy. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> I think master should always contain the latest >>> >>stable >>> >> > code, >>> >> > > > >>>>>> and >>> >> > > > >>>>>>> be >>> >> > > > >>>>>>>>>>>> periodically tagged with rc's and versions. >>> >> > > > >>>>>>>>>>>> All work should be done in personal forks and >>>feature >>> >> > > > >>>>>> branches. >>> >> > > > >>>>>>>>>>>> If the latest tag of master is an rc, then we >>>should >>> >> only >>> >> > be >>> >> > > > >>>>>>>> merging >>> >> > > > >>>>>>>>>>>> bugfixes, until the release. >>> >> > > > >>>>>>>>>>>> Immediately after tagging a version we decide >>>which >>> >> > feature >>> >> > > > >>>>>>>> branches >>> >> > > > >>>>>>>>>>>> and pull requests to pull in, and go for it. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> I don't think this is much different from what we >>> >>have, >>> >> > but >>> >> > > I >>> >> > > > >>>>>>> think >>> >> > > > >>>>>>>>>>>> that is good. >>> >> > > > >>>>>>>>>>>> The suggestions thus far, while interesting, don't >>> >> > increase >>> >> > > > >>>>>> our >>> >> > > > >>>>>>>>>>>> velocity in my opinion. Also, I can also pretty >>>much >>> >> > > guaranty >>> >> > > > >>>>>>> I'll >>> >> > > > >>>>>>>>>>>> screw it up for the next 3-4 versions. ( because >>>I'm >>> >> dumb >>> >> > ) >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Cheers, >>> >> > > > >>>>>>>>>>>> Jesse >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> On 2013-01-24, at 5:53 AM, Andrew Grieve < >>> >> > > > >>>>>> agri...@chromium.org> >>> >> > > > >>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks < >>> >> > > > >>>>>>>>>>> mich...@michaelbrooks.ca >>> >> > > > >>>>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> Before we move forward, I have a few questions >>>about >>> >> the >>> >> > > > >>>>>> "no >>> >> > > > >>>>>>>>> master" >>> >> > > > >>>>>>>>>>>>> approach. >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> There is *no* master branch, so that >>> >>community-driven >>> >> > pull >>> >> > > > >>>>>>>> requests >>> >> > > > >>>>>>>>>>> will >>> >> > > > >>>>>>>>>>>> be >>> >> > > > >>>>>>>>>>>>>> forced to think about which branch to request >>> >>against. >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> - Andrew, can you cite other projects that do not >>> >>use a >>> >> > > > >>>>>> master >>> >> > > > >>>>>>>>>> branch? >>> >> > > > >>>>>>>>>>>> This project is my first time using git / github, >>>so >>> >>I >>> >> > don't >>> >> > > > >>>>>> have >>> >> > > > >>>>>>>>> much >>> >> > > > >>>>>>>>>> to >>> >> > > > >>>>>>>>>>>> draw from. I was going off of others' suggestions >>>on >>> >> this >>> >> > > > >>>>>> thread >>> >> > > > >>>>>>>>> when I >>> >> > > > >>>>>>>>>>>> proposed the names. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> - On Github, you must have a default branch. If >>>not >>> >> > > > >>>>>> master, it >>> >> > > > >>>>>>>> must >>> >> > > > >>>>>>>>>> be >>> >> > > > >>>>>>>>>>>>> something else. So, users are not forced to think >>> >>about >>> >> > the >>> >> > > > >>>>>>>> branch >>> >> > > > >>>>>>>>> to >>> >> > > > >>>>>>>>>>>> send >>> >> > > > >>>>>>>>>>>>> a pull request again... they will likely just use >>> >>the >>> >> > > > >>>>>> default. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Hmm, good point. The goal is to get people >>> >>downloading >>> >> > > > >>>>>> Cordova >>> >> > > > >>>>>>> for >>> >> > > > >>>>>>>>> use >>> >> > > > >>>>>>>>>> to >>> >> > > > >>>>>>>>>>>> end up with Stable, and for developers to send >>>pull >>> >> > requests >>> >> > > > >>>>>>>> against >>> >> > > > >>>>>>>>>> dev. >>> >> > > > >>>>>>>>>>>> With a forced default branch, I don't think we can >>> >> > > accomplish >>> >> > > > >>>>>>> this. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> - Why is the "stable" branch not just "master"? >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> My thinking was that it's not obvious whether >>>Master >>> >>== >>> >> > > > >>>>>> bleeding >>> >> > > > >>>>>>>>> edge, >>> >> > > > >>>>>>>>>> or >>> >> > > > >>>>>>>>>>>> Master == Stable version. Using the names "dev" >>>and >>> >> > "stable" >>> >> > > > >>>>>>> makes >>> >> > > > >>>>>>>>> it a >>> >> > > > >>>>>>>>>>> bit >>> >> > > > >>>>>>>>>>>> clear. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> So... If github forces us to have a default >>>branch, >>> >>I'm >>> >> > > > >>>>>> thinking >>> >> > > > >>>>>>>> that >>> >> > > > >>>>>>>>>>>> having users send pull requests against "dev" is >>>more >>> >> > > > >>>>>> valuable >>> >> > > > >>>>>>> than >>> >> > > > >>>>>>>>>>> having >>> >> > > > >>>>>>>>>>>> people download the latest "stable" by default. If >>> >> people >>> >> > > are >>> >> > > > >>>>>>>> pulling >>> >> > > > >>>>>>>>>>> code >>> >> > > > >>>>>>>>>>>> from github rather than from our release .zip >>>files, >>> >> then >>> >> > > > >>>>>> it's >>> >> > > > >>>>>>>> likely >>> >> > > > >>>>>>>>>>> they >>> >> > > > >>>>>>>>>>>> want to hack on it anyways, or that they want the >>>dev >>> >> > > > >>>>>> version to >>> >> > > > >>>>>>>> see >>> >> > > > >>>>>>>>> if >>> >> > > > >>>>>>>>>>>> bugs are fixed. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Soo.... Here's version #3! If anyone can think of >>> >>how to >>> >> > > > >>>>>> keep the >>> >> > > > >>>>>>>>> three >>> >> > > > >>>>>>>>>>>> branches while addressing being forced to have a >>> >>default >>> >> > > > >>>>>> branch, >>> >> > > > >>>>>>>> feel >>> >> > > > >>>>>>>>>>> free >>> >> > > > >>>>>>>>>>>> to speak up! :) >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Cordova repositories have two main branches: >>> >> > > > >>>>>>>>>>>> 1. master >>> >> > > > >>>>>>>>>>>> 2. next >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Topic branches exist for collaborating on >>>features, >>> >>or >>> >> for >>> >> > > > >>>>>>>>> code-review >>> >> > > > >>>>>>>>>>>> purposes. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Cordova uses tags to label releases. >>> >> > > > >>>>>>>>>>>> - Each release candidate has a tag. e.g. >>>"2.2.0rc1" >>> >> > > > >>>>>>>>>>>> - Each release has a tag. e.g. "2.2.0" >>> >> > > > >>>>>>>>>>>> - The "latest" tag points to the last stable >>>release >>> >> (this >>> >> > > > >>>>>>> follows >>> >> > > > >>>>>>>>> npm >>> >> > > > >>>>>>>>>>>> conventions) >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> 1. The "next" branch. >>> >> > > > >>>>>>>>>>>> - This branch is used only when in the process of >>> >>doing >>> >> a >>> >> > > > >>>>>>> release. >>> >> > > > >>>>>>>>>>>> - All tags are created from this branch. >>> >> > > > >>>>>>>>>>>> - All release-candidate bug-fixes are done on this >>> >> branch. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> 2. The "master" branch. >>> >> > > > >>>>>>>>>>>> - When not in the release-process, all commits are >>> >>made >>> >> > here >>> >> > > > >>>>>>>>>>>> - When in the release-process, all non-bugfix >>>commits >>> >> are >>> >> > > > >>>>>> made >>> >> > > > >>>>>>>> here >>> >> > > > >>>>>>>>>>>> - This is where topic-branches are merged into. >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> Cutting a release: >>> >> > > > >>>>>>>>>>>> 1. git checkout next && git merge --ff-only master >>> >> > > > >>>>>>>>>>>> 2. Test test test! >>> >> > > > >>>>>>>>>>>> 3. Fix bugs by committing them directly to "next" >>>and >>> >> then >>> >> > > > >>>>>> doing >>> >> > > > >>>>>>> a >>> >> > > > >>>>>>>>>> non-ff >>> >> > > > >>>>>>>>>>>> merge of next into master >>> >> > > > >>>>>>>>>>>> 4. Tag release candidate >>> >> > > > >>>>>>>>>>>> 5. Repeat steps 2-4 as necessary >>> >> > > > >>>>>>>>>>>> 6. Tag the release (both by version and by >>>updating >>> >>the >>> >> > > > >>>>>> "latest" >>> >> > > > >>>>>>>> tag) >>> >> > > > >>>>>>>>>>>> 7. Create distribution .zip file >>> >> > > > >>>>>>>>>>>> 8. Test one last time using the dist files >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> Thanks, >>> >> > > > >>>>>>>>>>>>> Michael >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>> On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux < >>> >> > b...@brian.io >>> >> > > > >>>>>>> >>> >> > > > >>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>> I'm liking it. Start in 2.5? >>> >> > > > >>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj < >>> >> > f...@adobe.com >>> >> > > > >>>>>>> >>> >> > > > >>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>>>> Looks great Andrew! >>> >> > > > >>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>> If everyone's on board, how are we going to >>>test >>> >>run >>> >> > > > >>>>>> this? >>> >> > > > >>>>>>>> Flip a >>> >> > > > >>>>>>>>>>>>> switch >>> >> > > > >>>>>>>>>>>>>>> at a certain point, give it a shot with one >>>repo >>> >>for >>> >> > one >>> >> > > > >>>>>> RC? >>> >> > > > >>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>> On 1/22/13 12:29 PM, "Andrew Grieve" < >>> >> > > > >>>>>> agri...@chromium.org> >>> >> > > > >>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> Braden, you're right. I've now done some local >>> >> playing >>> >> > > > >>>>>>> around >>> >> > > > >>>>>>>> in >>> >> > > > >>>>>>>>>>> git, >>> >> > > > >>>>>>>>>>>>> and >>> >> > > > >>>>>>>>>>>>>>>> have an updated proposal that uses merges >>> >>instead of >>> >> > > > >>>>>>> deleting >>> >> > > > >>>>>>>>>>>> branches. >>> >> > > > >>>>>>>>>>>>>>>> PTAL: >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> Cordova repositories have three main branches: >>> >> > > > >>>>>>>>>>>>>>>> 1. stable >>> >> > > > >>>>>>>>>>>>>>>> 2. next >>> >> > > > >>>>>>>>>>>>>>>> 3. dev >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> Topic branches also exist for collaborating on >>> >> > > > >>>>>> features, or >>> >> > > > >>>>>>>> for >>> >> > > > >>>>>>>>>>>>>>>> code-review >>> >> > > > >>>>>>>>>>>>>>>> purposes. >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> There is *no* master branch, so that >>> >> community-driven >>> >> > > > >>>>>> pull >>> >> > > > >>>>>>>>>> requests >>> >> > > > >>>>>>>>>>>>> will >>> >> > > > >>>>>>>>>>>>>>>> be >>> >> > > > >>>>>>>>>>>>>>>> forced to think about which branch to request >>> >> against. >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> 1. The "stable" branch. >>> >> > > > >>>>>>>>>>>>>>>> - Sits at the latest stable release of cordova >>> >> > > > >>>>>>>>>>>>>>>> - This changes only when doing fast-forward >>> >>merges >>> >> > from >>> >> > > > >>>>>>> "next" >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> 2. The "next" branch. >>> >> > > > >>>>>>>>>>>>>>>> - This branch is used only when in the >>>process of >>> >> > doing >>> >> > > > >>>>>> a >>> >> > > > >>>>>>>>> release. >>> >> > > > >>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on >>>this >>> >> > branch. >>> >> > > > >>>>>>>>>>>>>>>> - All release-candidate bug-fixes are done on >>> >>this >>> >> > > > >>>>>> branch. >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> 3. The "dev" branch. >>> >> > > > >>>>>>>>>>>>>>>> - This is where non-release-candidate commits >>>are >>> >> done >>> >> > > > >>>>>>>>>>>>>>>> - This is where topic-branches are merged >>>into. >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> Cutting a release: >>> >> > > > >>>>>>>>>>>>>>>> 1. git checkout next && git merge --ff-only >>>dev >>> >> > > > >>>>>>>>>>>>>>>> 2. Test test test! >>> >> > > > >>>>>>>>>>>>>>>> 3. Fix bugs by committing them directly to >>>"next" >>> >> and >>> >> > > > >>>>>> then >>> >> > > > >>>>>>>>> doing a >>> >> > > > >>>>>>>>>>>>> non-ff >>> >> > > > >>>>>>>>>>>>>>>> merge of next into dev >>> >> > > > >>>>>>>>>>>>>>>> 4. Tag release candidate >>> >> > > > >>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary >>> >> > > > >>>>>>>>>>>>>>>> 6. Tag the release >>> >> > > > >>>>>>>>>>>>>>>> 7. Create distribution .zip file >>> >> > > > >>>>>>>>>>>>>>>> 8. Test one last time using the dist files >>> >> > > > >>>>>>>>>>>>>>>> 9. git checkout stable && git merge --ff-only >>> >>next >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden >>> >>Shepherdson >>> >> > > > >>>>>>>>>>>>>>>> <bra...@chromium.org>wrote: >>> >> > > > >>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>> I think deleting and recreating branches with >>> >>the >>> >> > same >>> >> > > > >>>>>> name >>> >> > > > >>>>>>>> can >>> >> > > > >>>>>>>>>>> cause >>> >> > > > >>>>>>>>>>>>>>>>> badness in git[1] because of remotes. It's >>>not >>> >> really >>> >> > > > >>>>>> the >>> >> > > > >>>>>>>> same >>> >> > > > >>>>>>>>>>> branch >>> >> > > > >>>>>>>>>>>>>> in >>> >> > > > >>>>>>>>>>>>>>>>> terms of commits, and git thinks that your >>>old >>> >> stable >>> >> > > > >>>>>> and >>> >> > > > >>>>>>> the >>> >> > > > >>>>>>>>> new >>> >> > > > >>>>>>>>>>>>>> stable >>> >> > > > >>>>>>>>>>>>>>>>> differ by all of each of their commits. Tags >>> >>can be >>> >> > > > >>>>>> moved >>> >> > > > >>>>>>>>>>>>> arbitrarily, >>> >> > > > >>>>>>>>>>>>>>>>> so I >>> >> > > > >>>>>>>>>>>>>>>>> think stable makes sense as a tag. I'm not >>>sure >>> >> about >>> >> > > > >>>>>> how >>> >> > > > >>>>>>>> best >>> >> > > > >>>>>>>>> to >>> >> > > > >>>>>>>>>>>>>> handle >>> >> > > > >>>>>>>>>>>>>>>>> next. >>> >> > > > >>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>> [1] >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>> >>> >> > > > >> >>> >> > > > >>> >> > > >>> >> > >>> >> >>> >> >>> >>>http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc >>> >> > > > >>>>>>>>>>>>>>>>> h >>> >> > > > >>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew >>>Grieve >>> >>< >>> >> > > > >>>>>>>>>>>>> agri...@chromium.org >>> >> > > > >>>>>>>>>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> Michal's attending hackathons for the week, >>>and >>> >> I'm >>> >> > > > >>>>>> not >>> >> > > > >>>>>>> sure >>> >> > > > >>>>>>>>> we >>> >> > > > >>>>>>>>>>>>> need >>> >> > > > >>>>>>>>>>>>>>>>> to >>> >> > > > >>>>>>>>>>>>>>>>> do >>> >> > > > >>>>>>>>>>>>>>>>>> a hang-out for this, as I think we really >>>are >>> >> quite >>> >> > > > >>>>>> close >>> >> > > > >>>>>>> to >>> >> > > > >>>>>>>>>>>>>> resolving >>> >> > > > >>>>>>>>>>>>>>>>>> this. I'd really like to resolve this ASAP >>>so >>> >>that >>> >> > we >>> >> > > > >>>>>>> don't >>> >> > > > >>>>>>>>> need >>> >> > > > >>>>>>>>>>> to >>> >> > > > >>>>>>>>>>>>>>>>> have >>> >> > > > >>>>>>>>>>>>>>>>> a >>> >> > > > >>>>>>>>>>>>>>>>>> code-freeze for this release. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> Here's a proposal: >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> Cordova repositories have three main >>>branches: >>> >> > > > >>>>>>>>>>>>>>>>>> 1. stable >>> >> > > > >>>>>>>>>>>>>>>>>> 2. next >>> >> > > > >>>>>>>>>>>>>>>>>> 3. dev >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> Topic branches also exist for collaborating >>>on >>> >> > > > >>>>>> features, >>> >> > > > >>>>>>> or >>> >> > > > >>>>>>>>> for >>> >> > > > >>>>>>>>>>>>>>>>> code-review >>> >> > > > >>>>>>>>>>>>>>>>>> purposes. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> There is *no* master branch, so that >>> >> > community-driven >>> >> > > > >>>>>> pull >>> >> > > > >>>>>>>>>>> requests >>> >> > > > >>>>>>>>>>>>>>>>> will >>> >> > > > >>>>>>>>>>>>>>>>> be >>> >> > > > >>>>>>>>>>>>>>>>>> forced to think about which branch to >>>request >>> >> > against. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> 1. The "stable" branch. >>> >> > > > >>>>>>>>>>>>>>>>>> - Sits at the latest stable release of >>>cordova >>> >> > > > >>>>>>>>>>>>>>>>>> - No one ever commits to the "stable" >>>branch. >>> >>It >>> >> > > > >>>>>> exists >>> >> > > > >>>>>>> only >>> >> > > > >>>>>>>>> as >>> >> > > > >>>>>>>>>> a >>> >> > > > >>>>>>>>>>>>>>>>>> short-cut for checking out the latest stable >>> >>tag. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> 2. The "next" branch. >>> >> > > > >>>>>>>>>>>>>>>>>> - This branch exists only when in the >>>process >>> >>of >>> >> > > > >>>>>> doing a >>> >> > > > >>>>>>>>>> release. >>> >> > > > >>>>>>>>>>>>>>>>>> - All tags (both stable and RC) are done on >>> >>this >>> >> > > > >>>>>> branch. >>> >> > > > >>>>>>>>>>>>>>>>>> - When a stable tag is done: >>> >> > > > >>>>>>>>>>>>>>>>>> - The existing "stable" branch is deleted >>> >> > > > >>>>>>>>>>>>>>>>>> - A new "stable" branch is created from >>> >>"next". >>> >> > > > >>>>>>>>>>>>>>>>>> - The "next" branch is deleted. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> 3. The "dev" branch. >>> >> > > > >>>>>>>>>>>>>>>>>> - This is where all commits are done >>> >> > > > >>>>>>>>>>>>>>>>>> - This is where topic-branches are merged >>>into. >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> Cutting a release: >>> >> > > > >>>>>>>>>>>>>>>>>> 1. Create "next" from the HEAD of "dev" >>> >> > > > >>>>>>>>>>>>>>>>>> 2. Test test test! >>> >> > > > >>>>>>>>>>>>>>>>>> 3. Fix bugs by committing them to "dev" and >>> >>then >>> >> > > > >>>>>>>>> cherry-picking >>> >> > > > >>>>>>>>>>>>> them >>> >> > > > >>>>>>>>>>>>>>>>> into >>> >> > > > >>>>>>>>>>>>>>>>>> "next" >>> >> > > > >>>>>>>>>>>>>>>>>> 4. Tag release candidate >>> >> > > > >>>>>>>>>>>>>>>>>> 5. Repeat steps 2-4 as necessary >>> >> > > > >>>>>>>>>>>>>>>>>> 6. Tag the release >>> >> > > > >>>>>>>>>>>>>>>>>> 7. Create distribution .zip file >>> >> > > > >>>>>>>>>>>>>>>>>> 8. Test one last time using the dist files >>> >> > > > >>>>>>>>>>>>>>>>>> 9. Delete "stable" >>> >> > > > >>>>>>>>>>>>>>>>>> 10. Create a new "stable" by branching from >>>the >>> >> HEAD >>> >> > > > >>>>>> of >>> >> > > > >>>>>>>> "next" >>> >> > > > >>>>>>>>>>>>>>>>>> 11. Delete the "next" branch >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal >>>Mocny >>> >>< >>> >> > > > >>>>>>>>>>>>> mmo...@chromium.org> >>> >> > > > >>>>>>>>>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>> Just going to throw out one of my personal >>> >> > > > >>>>>> requirements >>> >> > > > >>>>>>> for >>> >> > > > >>>>>>>>>>>>>> whatever >>> >> > > > >>>>>>>>>>>>>>>>>>> proposal we come up with, so it doesn't get >>> >>lost: >>> >> > > > >>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>> * Feature branches are great for feature >>>work >>> >> > and/or >>> >> > > > >>>>>>> large >>> >> > > > >>>>>>>>>>>>> sweeping >>> >> > > > >>>>>>>>>>>>>>>>>>> changes, as are JIRA bugs for tracking >>>them, >>> >>but >>> >> > > > >>>>>> cordova >>> >> > > > >>>>>>>> has >>> >> > > > >>>>>>>>>> many >>> >> > > > >>>>>>>>>>>>>>>>> many >>> >> > > > >>>>>>>>>>>>>>>>>>> trivial issues that could be fixed with >>> >> "drive-by" >>> >> > > > >>>>>>> patches >>> >> > > > >>>>>>>>> that >>> >> > > > >>>>>>>>>>>>>>>>> require >>> >> > > > >>>>>>>>>>>>>>>>>> as >>> >> > > > >>>>>>>>>>>>>>>>>>> little friction to commit as possible. >>> >> > > > >>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel >>> >>Kinard < >>> >> > > > >>>>>>>>>>>>> cmarc...@gmail.com >>> >> > > > >>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>> wrote: >>> >> > > > >>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>> How about if there is a specific straw man >>> >> > proposal >>> >> > > > >>>>>> at >>> >> > > > >>>>>>> the >>> >> > > > >>>>>>>>>>>>>>>>> beginning >>> >> > > > >>>>>>>>>>>>>>>>> of >>> >> > > > >>>>>>>>>>>>>>>>>>>> the face-time? Then the folks that are in >>> >> > agreement >>> >> > > > >>>>>>> won't >>> >> > > > >>>>>>>>> need >>> >> > > > >>>>>>>>>>>>> to >>> >> > > > >>>>>>>>>>>>>>>>> say >>> >> > > > >>>>>>>>>>>>>>>>>>>> anything ;-) >>> >> > > > >>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>> Seriously, making adjustments to something >>> >> > tangible >>> >> > > > >>>>>> is >>> >> > > > >>>>>>>>> easier >>> >> > > > >>>>>>>>>>>>>> than >>> >> > > > >>>>>>>>>>>>>>>>>>>> instantiating it from scratch. A volunteer >>> >>for a >>> >> > > > >>>>>> very >>> >> > > > >>>>>>>> simple >>> >> > > > >>>>>>>>>>>>>>>>> writeup >>> >> > > > >>>>>>>>>>>>>>>>> on >>> >> > > > >>>>>>>>>>>>>>>>>>> the >>> >> > > > >>>>>>>>>>>>>>>>>>>> wiki? >>> >> > > > >>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>> -- Marcel Kinard >>> >> > > > >>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote: >>> >> > > > >>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>>> Okay gentlemen, I think there have been >>> >> countless >>> >> > > > >>>>>> good >>> >> > > > >>>>>>>>> points >>> >> > > > >>>>>>>>>>>>>>>>> made >>> >> > > > >>>>>>>>>>>>>>>>>> from >>> >> > > > >>>>>>>>>>>>>>>>>>>>> all >>> >> > > > >>>>>>>>>>>>>>>>>>>>> parties, but also some bike-shedding. >>> >> > > > >>>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>>> Perhaps it is time to schedule some >>> >>face-time >>> >> to >>> >> > > > >>>>>> better >>> >> > > > >>>>>>>>>>>>>>>>> articulate >>> >> > > > >>>>>>>>>>>>>>>>>> some >>> >> > > > >>>>>>>>>>>>>>>>>>> of >>> >> > > > >>>>>>>>>>>>>>>>>>>>> the finer points, and to help come to >>>some >>> >> > > > >>>>>> consensus? >>> >> > > > >>>>>>>>>>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>>>>>>>>>>> -Michal >>> >> > > > >>>>>>>>>>>>> >>> >> > > > >>>>>>>>>>>> >>> >> > > > >>>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>>> -- >>> >> > > > >>>>>>>>>> @purplecabbage >>> >> > > > >>>>>>>>>> risingj.com >>> >> > > > >>>>>>>>>> >>> >> > > > >>>>>>>>> >>> >> > > > >>>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> >>> >> > > > >>>>>>> -- >>> >> > > > >>>>>>> @purplecabbage >>> >> > > > >>>>>>> risingj.com >>> >> > > > >>>>>>> >>> >> > > > >>>>>> >>> >> > > > >>>>> >>> >> > > > >>>>> >>> >> > > > >>>> >>> >> > > > >>> >>> >> > > > >>> >>> >> > > > >>> -- >>> >> > > > >>> @purplecabbage >>> >> > > > >>> risingj.com >>> >> > > > >> >>> >> > > > >> >>> >> > > > >>> >> > > > >>> >> > > >>> >> > >>> >> >>> >>> >
