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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > >> Inline image got mangled, here it is linked: http://cl.ly/MOrD > >> > >> > >> On Thu, Jan 24, 2013 at 1:39 PM, Shazron <[email protected]> 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 <[email protected] > >wrote: > >>> > >>>> Nice! even simpler. :) > >>>> > >>>> > >>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <[email protected]> > 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 < > [email protected] > >>>>>> 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 < > >>>> [email protected] > >>>>>>> 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 <[email protected]> > >>>>> wrote: > >>>>>>> > >>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson < > >>>>>>> [email protected] > >>>>>>>>> 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 < > >>>>>>>> [email protected] > >>>>>>>>>> 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 < > >>>> [email protected]> > >>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks < > >>>>>>>>> [email protected] > >>>>>>>>>>> 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 <[email protected] > >>>>> > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> I'm liking it. Start in 2.5? > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <[email protected] > >>>>> > >>>>>> 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" < > >>>> [email protected]> > >>>>>>> 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 > >>>>>>>>>>>>>> <[email protected]>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 < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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 > >
