Yes! That the idea. Not to actually take any control away from the maintainers but to open up the field to branching and experimental work, while giving the maintainers the ability to easily cherry pick the desirable branches.

To me, that's *the* main difference in distributed rcs, you *pull* from other people, not *push* into a central repository.  

On Thu, Jan 29, 2009 at 11:22 PM, Bob Hutchison <hutch-lists@recursive.ca> wrote:
Hi,

On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:

> It would be, but (at the risk of being presumptuous) allowing for easy
> forks and experimentation is not the goal of the maintainers.
>
>
> I could see that as being the goal of a person that wanted to fork the
> code and/or experiment.  As Edi said, you have the freedom to fork...,
> or not.

This 'fork' business when using git seems to be more due to github
than git, and doesn't normally mean a forked project like, say, the
Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a
bunch of tools that allow for core maintainers (e.g. Edi and Hans) to
keep control of the code base but to have other people contribute
(without worrying about things like commit privileges, and messed up
patch files). This made a *huge* difference to the Rails project
starting last April or so. These two links give more information along
the lines of that on the page linked to by cmo-0:

<http://github.com/guides/fork-a-project-and-submit-your-modifications>
<http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch>

And they give you shiny baubles like:

<http://github.com/madrobby/scriptaculous/network>

This is the arbitrarily chosen (near the top of the most-forked list
with a few forks yet to be pulled) scrit.aculo.us project, 292 forks
-- but still only one script.aculo.us :-)

I've been using github for my company and my personal work for about
10 months now. Works well for me. Big wins:

-- works off line
-- branching and tagging easy and fast
-- master branch can be 'rebased' into the branches, and the branches
commited as though a single commit (you can, if you want, lose all
those micro commits and sub-branches -- if you look at the github
network/fork graph, each of the forks can be reduced into a single
'dot' on the master branch, or not).
-- commits are orders of magnitude faster than SVN, at least for me.

I think git might make things easier for Edi and Hans at the cost of
having to learn it. More importantly, things like Volkan's patch might
be better tested or improved by having people contribute to the fork
rather than the master branch. Keep this kind of thing out of their
hair until it's more ready.

Cheers,
Bob

>
>
> Chris.
>
> On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
>
>>> What is the plan for the git repository?  Why is it needed, what
>>> makes
>>> it useful?
>>
>> i find the following feature helpful (YMMV)
>>
>> http://github.com/guides/pull-requests
>>
>> it will be a helpful tool of using git to allow for easy forks and
>> experimentation and easy cherry pick any changes made by other forks.
>>
>> cmo-0
>>
>> On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner
>> <hans.huebner@gmail.com> wrote:
>>> Hi,
>>>
>>> bknr.net was temporarily down due to a power failure at the data
>>> center.  The machine is back up now.
>>>
>> I'm aware of the "centralized maintenance" "problem" of
>>> Subversion, but as Hunchentoot is not going to convert into a
>>> community project (i.e. we'll review all patches that we accept into
>>> the repository that eventually becomes the release), I'm not sure
>>> how
>>> another level of indirection helps.  It may be possible to convince
>>> us
>>> to switch to git if there is a good reason to do so, but that'd need
>>> some explanation.
>>>
>>> -Hans
>>>
>>> On Thu, Jan 29, 2009 at 18:28, William Halliburton
>>> <whalliburton@gmail.com> wrote:
>>>> Hello everyone...
>>>>
>>>> I would like to volunteer any amount of time needed to get Hans's
>>>> changes
>>>> folded into the main repository and/or get the development version
>>>> moving
>>>> forward and more accessible. I am working on a startup that is
>>>> currently
>>>> using hunchentoot and, as chance may have it, I am right about now
>>>> going to
>>>> be digging into hunchentoot and friends as part of a performance
>>>> and
>>>> understanding push.
>>>>
>>>> Currently the BKNR repository is down, but once it gets back up I
>>>> would like
>>>> to set up a git repository of flexi-streams, hunchentoot, chunga,
>>>> and drakma
>>>> and I invite anyone that wishes to help contribute to this effort.
>>>>
>>>> I am most interested in figuring out and testing the performance
>>>> characteristics of the libraries with respects to threading/non-
>>>> threading,
>>>> select/epoll, and proxy/no-proxy on SBCL and am most willing to
>>>> put in the
>>>> time and effort to develop and test these different scenarios.
>>>>
>>>> Thanks to everyone.
>>>>
>>>> Peace,
>>>> Will
>>>>
>>>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz <edi@agharta.de> wrote:
>>>>>
>>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo@ttmail.com
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> Thanks Hans Huebner for his kindly helps and Edi Weitz for his
>>>>>> uninterest in any effort.
>>>>>
>>>>> Volkan,
>>>>>
>>>>> If you think you're somehow entitled to an immediate reply or any
>>>>> action from me just because you sent a patch that is "not well
>>>>> tested"
>>>>> and "doesn't include any documentation", you're obviously living
>>>>> on a
>>>>> different planet or at least you don't know what it means to
>>>>> have a
>>>>> job and a family in addition to taking care of more than a dozen
>>>>> open
>>>>> source libraries in your spare time.  I might look at these
>>>>> patches if
>>>>> and when I find the time to work on Hunchentoot again or I might
>>>>> not.
>>>>> If that's not acceptable to you, the license on all of my libs
>>>>> always
>>>>> allows you to fork them and basically do with them whatever you
>>>>> want.
>>>>>
>>>>> For those of you who wonder why Hunchentoot and some other
>>>>> libraries
>>>>> have been in limbo for quite some time now, here's a quick
>>>>> explanation: A company paid Hans to make a couple of additions to
>>>>> Hunchentoot which are now in the bknr.net repository.  I also
>>>>> worked
>>>>> on this a bit in my spare time and added some code, mainly for
>>>>> performance improvements.  The good thing is that due to Hans'
>>>>> work
>>>>> the development version is much improved in several aspects over
>>>>> the
>>>>> current release.  The bad thing is that due to Hans' and my
>>>>> changes
>>>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be
>>>>> released together, because they are mutually incompatible with the
>>>>> released versions.  And, for them to become acceptable (for me)
>>>>> release versions, there's a certain amount of clean-up and
>>>>> documentation needed that still has to be done.
>>>>>
>>>>> Now, the deal with the afore-mentioned company was that they
>>>>> would pay
>>>>> Hans and me to do this clean-up and integration work so that we
>>>>> once
>>>>> again have "official" release versions that are feature-wise in
>>>>> sync
>>>>> with the current dev versions.  This hasn't happened so far, and
>>>>> right
>>>>> now I fail to see why I should spend a significant amount of my
>>>>> spare
>>>>> time to do this clean-up work when I have more interesting things
>>>>> to
>>>>> do.  /Maybe/, this will happen in the future (paid or unpaid), or
>>>>> maybe there'll at some point just be another Hunchentoot release
>>>>> based
>>>>> on 0.15.7 and the dev changes will be lost.  Until then, I think
>>>>> the
>>>>> current release isn't perfect, but certainly something that can be
>>>>> used (and is used) without significant problems.
>>>>>
>>>>> Cheers,
>>>>> Edi.
>>>>>
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel@common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel@common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel@common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>
>>
>>
>> --
>> It does not matter how fast your code is, if it does not work!
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel@common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel@common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

----
Bob Hutchison
Recursive Design Inc.
http://www.recursive.ca/
weblog: http://www.recursive.ca/hutch




_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel