well, for gods sake and (and for the peace of the bits on my ssd) I move my vote to +1 as well
LieGrue, strub ----- Original Message ----- > From: Kristian Rosenvold <[email protected]> > To: Maven Developers List <[email protected]>; Mark Struberg > <[email protected]> > Cc: > Sent: Tuesday, September 11, 2012 2:13 PM > Subject: Re: [VOTE] Move Maven projects sources to git > >> But GIT sucks a bit when it comes to projects like maven-shared and > maven-plugins which get released in portions. We already explained that with > long words and we might have found a compromise which doesn't hurt too > badly. But still it has to be verified if that works out. > > Tagging the whole repo svn-style definitely works, and the > maven-plugins repo isn't that big either. We could consider stephen's > subdivision suggestion, but really I think it's totally viable to just > leave one big repo. We're talking 37mb for the full history of > everything, give or take a few bytes. Not too much by any modern > standard. > >> We now count the year 1 after goog-vs-orcl and must really be cautious about > intellectual property! > > How is accepting a patch in Jira from user "fuzzyBear" without any > further credentials attached (and no visible identification of a real > or imagined person) different form a github pull request ? So while I > agree about being careful about IP, i can't see our current regime > being a bit different from github. You may argue that we'd want to > tighten this, but this is the current reality for over 1 million > committs. I have no idea of how many "John Smith" accounts there are > in our jira, but we pretend to ignore the fact. > > >> But here is another example where it did not work out: A few days ago a guy > pinged us on #maven about the osxappbundle-maven-plugin. He just found 20++ > versions around on github and none of them was working correctly. He didn't > even know that the original one was still maintained in SVN in codehaus. So > we > went through all the versions on github and most of them contained different > patches. And actually all of them only worked for a very specific situation. > There was exactly 0 of them which worked on all 3 last OSX versions! >> >> >> What does this mean? > > It means you can't ignore your community and not maintain software > when you're on git. But git has opened this entry point no matter > what, it's like a box that's been opened for the whole community and > there's no way back on that. The "exclusive modification" right > that > svn commit bit used to mean is gone. Once you learn to maintain a git > fork you can permanently maintain a fork much simpler than before. > It's actually something I think we should embrace, not frown upon. > > On my last project, we had *permanent* forks of three major frameworks > that git allowed us to rebase and maintain with minimal or no effort. > Characteristic of these patches were that > A) we had submitted them but they were rejected > B) we were invested in deprecated stuff that the communit weren't > maintaing any more > C) it was simply not of a quality that would be accepted > > Looking blindly at the github network graph does not give you this > story, and it's like there's a whole new world of options available to > OSS users. The act of submitting a patch (=pull request) simply means > the creator of the patch is interested in submitting. The fact that I > can browse all kinds of different hacks people have applied to my code > does not really mean they are submitted or intended for submission. > > Combined with mailing list & issue tracker activity, the stuff going > on at github /is/ your community. If you see something cool in a > branch on github, just add a comment requesting the author to submit > this as a patch (or pull request if you permit it). > > If we can't accept pull requests we'll just have to do some other cool > hack. Maybe we could write github plugin that could auto-submit a jira > ;) It's all options, and we decide > > > Kristian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
