On Tue, Sep 14, 2010 at 9:30 AM, Toni Menzel <t...@okidokiteam.com> wrote:
> No, its not abandoning SVN. Its offering an extra choice for pulling more > people in. Well, I got the impression that SVN is going to be gone soon. Pulling in more people == Good Thing. Right way forward is not clear cut IMHO. > Thank god you are not on twitter, Niclas ;) I get your noise over Google Buzz... > But that move speeded up to get into discussion with a concrete "problem > space". If you want to pick something good out of that. Yes, I am not against moving to GitHub, it has been considered for a long time, both in Qi4j and "we who worry about infra". So, sure, discussion started, kudos. > We need to have a swap over date > Old repos are still in place. Well, what exactly happens when John Hacker makes some additions to Pax Exam. How does those make their way back to "recommended fork", and likewise how does SVN commits make their way to the GitHub repos?? I don't see a workable process at the moment. Please enlighten me... > We neeed to update the documentation to reflect that swap over > Docs coming up. I see them more as a result of the discussions happening on > the Mailinglist/Feedback. Ok, if there is no "swap over" and some kind of working co-existence the doc situation is less critical. > How is authorization going to work in practice > Practices are not enforced automatically, yet. > But the OPS4J rules still apply, and that what at least i see the true > value. > If you see OPS4J anywhere on the planet, you can be sure to be able to take > it, contribute, collaborate. This is what should be spread. Just because we > have a nifty solution for authenticating the hosted svn repo does not > necessarily mean OPS4J defines+validates itself against that > "implementation". Does it ? Of course not. What defines OPS4J is "No barrier" and I have always wanted to strive towards that goal. In my opinion "No Barrier" is defined along multiple axises; * Inclusion - This looks fun, I want to work on it. * Authorization - I am automatically granted access, and no 'delay' in the process of getting things committed. * Technical - I already understand the tools I need to comply with, and don't have a large learning curve. * Social - I will be respected for my work and my valued feedback, not for my 'status'. * Freedom - No unreasonable limits are placed on my work and work that others are contributing. * Financial - I don't need to spend any money, and I can spend as little time as I would like. * Opportunity - I can work on any aspect of the community and its tools, not only code and docs. So, whether a "Git only" situation (assuming with GitHub) is lowering or raising the barriers is IMHO not clear cut case. It seems we are raising the bar in the "Authorization" area, and in the "Technical" one it may be one way or the other. The rest practically same, I think. If we are having both SVN and GitHub, then I would like to see the "automation" involved to make that a non-manual process, otherwise I suspect things will fall through the cracks and soon only the most experienced would have any clue about the situation... And likewise, how is a GitHub-only setup (with OPS4J org) going to work in practice? Does it mean we all commit to the same repo, or is there going to be pull requests and all of that, or are we sharing patches with email first... ? Perhaps distributed systems are great, BUT just like what happened to the PC, it quickly becomes unmanageable and one need to re-introduce processes and some time of central guidance. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
