On 11/4/07 8:33 AM, "Demetrios Kyriakis" <[EMAIL PROTECTED]> 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
