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