On Tue, Sep 14, 2010 at 4:23 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
> 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... > Per Project we should decide on either svn or git as official repositories. Though, all git imports are done in a way that it still "knows" about the svn repo it originally came from. See: -- snip --- zazu:org.ops4j.pax.exam tonit$ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true autocrlf = false [svn-remote "svn"] url = https://scm.ops4j.org/repos/ops4j/projects/pax/exam fetch = :refs/remotes/git-svn [remote "origin"] url = g...@github.com:ops4j/org.ops4j.pax.exam1.git fetch = +refs/heads/*:refs/remotes/origin/* -- snap -- this effectively means that you can still completely merge in from svn-remote via the "git svn <command>" commands. Though, this perfectly works for undecided time and not too heavy parallel developments on both ends. In the end it should be one or the other. For OPS4J zero barrier mantra we could think of mantaining a svn mirror of the git based projects for people without git knowledge to jump straight in. - but i think its just not necessary. You could have argued the same way with CVS, when choosing Subversion at the very beginning. > > > 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. > Git/Github probably brings fun+contributors/visibility. Which equals to "more fun" . > > * Authorization - I am automatically granted access, and no 'delay' > in the process of getting things committed. > This is probably a technical drawback as github authorization is not automated - probably never will be. But git promotes a totally different style of contributing than svn. So to contribute, its not that much mandatory to get commit access to the "official" repo. Still, getting push grants to ops4j projects is something should get easier than a rice in Hongkong.. > > * Technical - I already understand the tools I need to comply with, > and don't have a large learning curve. > Yeah, there is a steeper learning curve. But i never have heard anyone regretting it. > > * Social - I will be respected for my work and my valued feedback, > not for my 'status'. > Totally the way github works. Together with OPS4J infrastructure (Mailinglist - most valuable, you cannot "buy" elsewhere, Jira,Confluence,Deployment Infrastructure, hook into existing projects with minimal effort) > * 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. > +1. And integrating Git/Github is an opportunity. > > > 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... ? > As written above, github would be an alternative scm home for new or existing projects. To ease it not not make it too complex, i would make a project the one SCM or the other + state on the website/rules that if someone is not comfortable with - lets say - git but wants to contribute to Pax Exam, he has many choices: Option 1: - download from http download url (github offers that) - change/modify - 1a contribute back via: sending a patch to the List/Jira - 1b svn add <laboratory> , commit changed code there thats the very ugly option but maybe worth to offer at least Option 2: Like they do at github, show the minimal steps you need to 1. install git 2. checkout 3. commit back Thats really minimal. And as a sidekick he gets to know git. for free. In the end its a higher technical barrier because its not as spread in the enterprise world than svn. So true. But this offer here can probably contribute to change that a little. > > 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. > - what exactly is.. PC ? There will be - per project - either a svn repo or a git repo . Any fork is not part of the ops4j job, is it ? So there is not much more to mantain. ? QUESTION ========== How do we procede ? What do we need to vote on ? How to carry on with the following in transit projects: Projects which are more on github than on svn: pax url -> on github, contains already a new module (url-aether) which will become the successor of pax url mvn handler pax runner -> on github, contains already a change (feature branch) for upcoming 1.6 release pax exam -> minimal changes of the 1.x line to use the aforementioned project versions pax exam 2 -> totally different spin of, cut from svn in last winter Projects awaiting transition: Pax Web : this is very interesting because, there is a concrete usecase with a major patch (see other ML thread). It also is interesting because it has - at least from my view - the most diverse contribution history. Meaning, once in a while, totally different/new contributors step in. This could be a good showcase how well git can be accepted. cja, Toni > 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 > -- *Toni Menzel || **http://okidokiteam.com*
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
