> 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
