cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: too long to package a release?
Date Wed, 20 Feb 2013 19:24:34 GMT
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 <fil@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" <agrieve@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 <fil@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" <mmocny@chromium.org> wrote:
>>>
>>> >oooo I didn't know that.  Thanks!
>>> >
>>> >
>>> >On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>>> ><gibson.becky@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 <mmocny@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.becky@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
>>><cmarcelk@gmail.com>
>>> >> > wrote:
>>> >> > >
>>> >> > > > Nice! Thanks, Andrew!
>>> >> > > >
>>> >> > > > -- Marcel Kinard
>>> >> > > >
>>> >> > > > On Feb 7, 2013, at 2:59 PM, Andrew Grieve
>>><agrieve@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
>>> >><cmarcelk@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 <purplecabbage@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
>>><shazron@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
>>><shazron@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 <
>>> >> > > agrieve@chromium.org
>>> >> > > > >>> wrote:
>>> >> > > > >>>>>
>>> >> > > > >>>>>> Nice! even simpler. :)
>>> >> > > > >>>>>>
>>> >> > > > >>>>>>
>>> >> > > > >>>>>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <
>>> >> purplecabbage@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 <
>>> >> > > > >> agrieve@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 <
>>> >> > > > >>>>>> braden@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 <
>>> >> > > purplecabbage@gmail.com>
>>> >> > > > >>>>>>> wrote:
>>> >> > > > >>>>>>>>>
>>> >> > > > >>>>>>>>>> On Thu, Jan 24, 2013 at 11:09 AM, Braden
>>>Shepherdson <
>>> >> > > > >>>>>>>>> braden@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 <
>>> >> > > > >>>>>>>>>> purplecabbage@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 <
>>> >> > > > >>>>>> agrieve@chromium.org>
>>> >> > > > >>>>>>>>> wrote:
>>> >> > > > >>>>>>>>>>>>
>>> >> > > > >>>>>>>>>>>> On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>>> >> > > > >>>>>>>>>>> michael@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 <
>>> >> > fil@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" <
>>> >> > > > >>>>>> agrieve@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
>>> >> > > > >>>>>>>>>>>>>>>> <braden@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
>>> >><
>>> >> > > > >>>>>>>>>>>>> agrieve@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
>>> >><
>>> >> > > > >>>>>>>>>>>>> mmocny@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 <
>>> >> > > > >>>>>>>>>>>>> cmarcelk@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
>>> >> > > > >>
>>> >> > > > >>
>>> >> > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
>>>
>

Mime
View raw message