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... (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
