Re: DataViews - Proposal - move to sourceforge!

From: Kevin Menard (kmenar..ervprise.com)
Date: Sun Nov 04 2007 - 09:51:14 EST

  • Next message: Mike Kienenberger: "Re: DataViews - Proposal - move to sourceforge!"

    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