2013/6/29 Stephen Connolly <[email protected]> > > > On Saturday, 29 June 2013, Baptiste MATHUS wrote: > >> OK. >> Trying to sum up what was said, please comment/complete: >> >> * Basically, the majority seems to be OK with the /idea of a migration/. >> ** But this would be really better done in a all-or-nothing way, so that >> there's not many scm technos used at mojo@codehaus. >> >> * Hosting >> ** Git is definitely already supported at Codehaus >> > > Yes it is > > >> ** IIUC Stephen, we would still need to get some more rights or something >> (I suppose this is because we, by nature, create a lot of repos, so this is >> unlikely something that could be left as-it without much hassle). >> > > I suspect more training is all... But we need to check with Ben > > >> ** There's a debate of where the canonical repo should stay: somewhere >> at Codehaus, or at GitHub? (anyway, one would then be the mirror of the >> other) >> > > If we are keeping the org.codehaus.mojo groupId then I say canonical repo > has to be at codehaus.... > > My €0.02 is that projects hosted at codehaus should be canonical at > codehaus... However this is AFAIK not the required policy of codehaus: > i.e. Bob and Ben do not force this > > If the majority of people want to move the canonical elsewhere then I am > fine with that, I just disagree > > >> * Contribution: lowering the barrier or not? >> ** Some think that would help people propose patch/contribute, and also >> help committers here to integrate patches btw. >> ** Some are worried that would mainly cause the death to many projects >> (here, that would affect some mojos?). Btw, I'd be interested in having >> examples of that kind of death. >> > > I think death fears are more relevant if we have a duality if SCM > technologies > > >> >> * Technical aspects: >> ** Migration could reasonably be automated. One git repo per mojo for >> example. That's something many of us have already done, so I suppose that's >> not the main issue. >> >> WDYT? Have I forgotten something? >> > > How would the sandbox work if we move to git? > > Right now it is easy to start up a plugin in sandbox and migrate to > released with history retention. > > I think with GIT you'd either need to let everyone create a repo per > plugin for sandbox plugins (could get messy real fast, especially with > refactoring and renames that can happen in the sandbox) or you start each > plugin from a rootless branch in a sandbox repo and have a branch per > plugin (at least makes cutting out history easy, though you loose the cross > plugin refactoring [for most git users... Kristian, a few others and maybe > myself probably have enough git-foo to merge two histories in a third > rewritten branch and then pull the history together] that svn allows) >
> The question is though whether that is critical > > Oh and Sandbox is not an academic problem, in my view one of mojo's > strengths is as a plugin breeding ground... Letting plugins start easy and > grow in a tended community... (Most of the maven committers are semi-active > here also) > > Which is why I view mojo hosted plugins as better quality than pretty much > all the other plugins out there (there are the few odd gems, but as a > stereotype I think it is a fair one) > > If we don't make it easy to start sandbox plugins, then I view that as a > major negative... > +1. I didn't want to mix my opinions in the previous summary mail, but I was about to say something along those lines. I think mojo-sandbox should be a repository that will have the current content that can be found at http://svn.codehaus.org/mojo/trunk/sandbox/ as its root. The major issue with Git with this kind of setup is that Git isn't designed at all to tag a subpart of a repository. But as sandbox isn't releasable, that's not an issue. This way, there will still be easy to start experimenting new ideas in sandbox without having to ask anyone. If we agree on this, then the next (big) thing is, how should we technically handle a plugin promotion out of sandbox? And basically, this boils down to: what do we want to be able to track in the history of a plugin in sandbox? In fact, if we filter-branch --subdirectory-filter the-promoted-mojo, it will have all its sha1 changed. But for sandbox plugins, this might certainly be a non-issue. If it is, then we can very easily etch the old-sha1 as a property line in the rewritten commit (I did that a few weeks ago for an internal git repo). Btw, I suppose we will also keep the git-svn-id (or whatever the name) to be able to find a commit in a git repo that was actually a converted svn one. Cheers > > (That is not to say that we do a great job of curating our plugins... I > think we need to revisit the ugin owners... I will take a look at the > emeritus watch list email I sent recently and apply that... Then we should > revisit owners and cull ownerless plugins again) > > >> If we want to call for a vote about this, I guess we still need >> discussion so that it doesn't get many -1 immediately and everybody loses >> his time and we don't move forward :). >> >> Cheers >> >> >> 2013/6/29 Fred Cooke <[email protected]> >> >> Well Robert, it might not affect some, but it definitely affects others. >> Take me for example. I don't have and won't install SVN on my main dev >> machine. This mac is glacial at best, especially in a hot climate (30C >> where I live at the moment), so I don't dev on it much. If the mojos of >> interest to me had been in Git I'd have put some commits in before I >> discovered the release procedure stuff and decided not to. It's still on my >> TODO to convert the repos I need and make the changes I need, because it's >> a slight hassle and I'm far more than slightly busy. If it was already in >> Git it'd be clone, commit, push to github, done. So yeah, you'd have had >> some work out of me for sure. >> >> >> On Fri, Jun 28, 2013 at 10:12 PM, Robert Scholte < >> [email protected]> wrote: >> >> Yes ,I have these same concerns as Mark. >> >> Of all the Maven related projects which have been moved from SVN to GIT I >> haven't seen more patches then before. So I'm not sure if this will >> increase the number of contributions. >> Don't get me wrong: I do understand the advantages of GIT, but especially >> the cloning part makes it a lot easier to maintain your own version (you >> don't depend on one of the plugin maintainers to approve patches, if any is >> still alive). >> >> Robert >> >> >> On Fri, 28 Jun 2013 16:55:52 +0200, Mark Struberg <[email protected]> >> wrote: >> >> >> >> There were some projects which moved to GIT. >> >> But after a short while they are now all DEAD! >> >> This has nothing to do with GIT itself (which I love), but with the >> missing 'ownership'. >> It's totally easy on github to just fork a project and fix your bug there >> - fully agree! >> But what about merging this stuff back? Well, this just does not happen >> most of the time. >> >> And this is the reason why I still love to have those projects over here >> at codehaus, eclipse or apache. >> >> Mostly because all people then know where to get the origin from. >> >> Again, this has nothing to do with GIT vs SVN. It just has to do with >> having some 'cannonical' source or not. >> >> LieGrue, >> strub >> >> >> >> >> ______________________________**__ >> From: Jochen Wiedmann <[email protected]> >> To: [email protected] >> Sent: Friday, 28 June 2013, 16:07 >> Subject: Re: [mojo-dev] Re: Mojo GIT migration or mirroring? >> >> >> >> Just asking: Does Github offer to provide an SVN mirror? Or is there any >> other way to have a mirror without too much hazzle? >> >> >> >> >> >> On Fri, Jun 28, 2013 at 9:50 AM, Fred Cooke <[email protected]> wrote: >> >> >> >> >> For GIT users there are several ways to work with SVN, so that's >> probably why this isn't that urgent. >> >> >> That's not really a good reason not to, because: >> >> * The SVN >> Git process isn't fast (because SVN is itself SLOW) >> * Each converter has to find motivation to bother setting this up and >> doing it in the first place. (read, they'll just not bother most of the >> time) >> >> * Each conversion will have a different set of hashes even if the >> other parameters are the same and thus won't be able to be collaborated >> between effectively. Having a single official mirror means others can >> effectively work together on "it" with the final result pulled back into >> SVN when ready and then automatically pushed back to Git again. The work >> flow is a pain, but still a lot better than suffering SVN in the first >> place. >> >> migrate > 1 official mirror (per mojo) > N unoffici >> >> -- >> Baptiste <Batmat> MATHUS - http://batmat.net >> Sauvez un arbre, >> Mangez un castor ! >> > > > -- > Sent from my phone > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
