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