On 09/11/2012 07:13 AM, Kristian Rosenvold wrote: >> 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. >
I would vote for just splitting the Maven plugins into separate git repos. I normally don't find myself needing to checkout/build/work on multiple plugins at once, so giving them each a separate lifecycle would be fine, IMO. But we could probably leave these migrations for later after we migrate Maven core and some of the other more monolithic projects. >> 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. > > I agree, if anything git patches give us a bit more protection regarding IP because it tracks the name and email of the author. In addition, we could make it our policy to not accept patches in git that don't appear to have a valid author name and email. >> 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
