On 11/4/07 8:33 AM, "Demetrios Kyriakis" <demetrios.kyriaki..ooglemail.com>
wrote:
>>
> Well I can give you a few reasons, but I suppose "true Apache believers"
> will dismiss them and will consider "flame" :). This is not my intention,
> but to give you another point of view - that of *your users*.
The only thing that is a flame is this preceding paragraph. You would have
done well to omit it.
> #1 - most people do open source work in their free time, and this for fun
> and only as long as it makes fun.
> (Well there might be exceptions - maybe on Apache.org there are more
> "employees" doing open source work in their "work time" than somewhere
> else).
For me, fun is getting something working. It is rewarding when something
gets accepted, but I can have fun otherwise. So, to each his own on this
one I guess.
> #2 - submitting patches to an issue tracking system is no fun.
> There's no direct feedback, there's no "instant gratification", and for sure
> it does not compare with a simply making a quick check in and getting
> feedback for your changes.
Once again, getting it working locally should be instant gratification. You
do have to realize that any commit affects a large number of people.
Additionally, the developers do not have the resources to do a full code
review of every commit. We try to stay on top of things to keep each other
in check, but there's a general sense of peer respect in that we trust what
each other is committing. If there are doubts on anything, a discussion
typically takes place on the developer list beforehand and any submissions
are given more consideration at that point.
What you are suggesting would lead to chaos.
Having said that, I've been a long time fan of using a distributed version
control system so that users looking to contribute could still use an SCM
tool. When Cayenne was hosted on ObjectStyle and I didn't have commit
access yet, I even mirrored a darcs repository. That may be a good option
for you as well (check out the tailor project).
> #2.1 - in many Apache projects, issues (with patches but with simple code
> snippets too) take months to get into the code - if they ever get. A simple
> browse of the Apache JIRA shows this state: there are even a few projects
> where this takes years :) - Velocity, JAMES, Commons VFS - just to mention a
> few (and your users know them even if they don't express their frustration
> with that state).
We are not any of those projects and thus we cannot comment on them, nor are
the criticisms applicable to us. If you have an issue with a patch attached
to a JIRA issue not being applied, please bring it up in a separate thread.
> #3 - getting commit rights is waaaay too complicated on Apache.org - on
> sourceforge it takes only one click :). If it's not OK what that developer
> does, the rights can be revoked anytime, and the code rollbacked - nobody
> gets upset and nobody is loosing time - the time frame where the contributor
> is in "fun state" is kept :).
There's a difference between the political and the technical ways of getting
commit access. I suppose technically there is a bit more work, as an infra
request needs to be set up. Yeah, a bit more overhead, but honestly, I'm
glad to have a direct conduit to the guys running the repo. I've never seen
the reliability problems that SF has with its repo.
From a political perspective, there's really nothing stopping us from
handing out commit rights on a whim. We don't want to, however, and that
wouldn't change if we were on SF.
> #4 - on SF unlike Apache.org most people spend no time on licensing
> discussions (nor really do they care) or voting with the most strange voting
> ever invented: "veto" for everybody :) :) :). (on Apache JAMES this veto
> this leads to constant blocking in the last 3 years, and on other projects
> to always choose the "least common denominator", or developers being
> Ueber-cautious - this simply kills creativity, and 100% kills fun :) ).
Unfortunately, this is true. It creates a lot of headaches for a lot of
people, however. Categorically incorrect licensing is used and it creates
problems for end users. That's one of the nice things about the ASF
projects -- a guarantee that the code you get can essentially be used any
way you like.
I think it's clear what the options really are:
1) Fork the code and take it to SF. I know you don't want to fork, but the
current devs are not going to move the project. Of course, we're not really
doing anything with it either, so there's opportunity for your fork to
succeed.
2) If it really boils down to commit privs, I think Craig is on the right
track. A proposal for a subproject incubator could be made.
3) If it really boils down to SCM tools, leave things as are and set up a
mercurial/darcs/bzr/whatever mirror and use that to develop against.
And with that, I'm removing myself from the thread unless something new is
added. It seems like the hide is gone off this dead horse.
-- Kevin
This archive was generated by hypermail 2.0.0 : Sun Nov 04 2007 - 10:51:50 EST