Awesome! Stoked to see "next" branches dropping for the upcoming 2.5.0rc's !
On 2/7/13 11:59 AM, "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 >> >>
