cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Kinard <cmarc...@gmail.com>
Subject Re: too long to package a release?
Date Thu, 07 Feb 2013 18:26:33 GMT
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