[hunchentoot-devel] Maximum Request Size

Sun Feb 1 04:06:00 UTC 2009

Egads.

My comment was not to beat the dead horse of why Git will save the  
world, but that using any other version control other than what the  
project is currently using is a distraction from the goal(s) of the  
project itself.  The Slime mailing list went through this same thing a  
while back, and I it never got resolved.

When I said "fork" I meant if you want to maintain the code under some  
version control, go right ahead, but don't clutter the mailing list  
with advocacy for version control.  On the other hand, I guess I could  
go to the version control mailing lists and tell them that they should  
be using Hunchentoot for their projects' web site.

Chris.

On Jan 29, 2009, at 10:22 PM, Bob Hutchison 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 at 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 at 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 at agharta.de> wrote:
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo at 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 at common-lisp.net
>>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at 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 at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel