On Thu, Sep 18, 2008 at 10:26 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote: > > "but they cannot require third parties to not sync it into their > > repos." --> Is this something Maven PMC is > > thinking-about/voted-on/discussing? basically overriding the current > > un-written policy of the incubator? Please let us know. > > Not yet. But my point is if Maven was NOT an Apache project, what COULD > we > do? > Just not build a repo at all? They could download and publish each of our releases and there's nothing wrong about it. It's just about what kind of practices *we* want to promote or discourage. It's just a judgment call, which is why I guess the issue is so disputed. Some people don't care which dependency they end up using, where it comes from, what its quality or license are. Why not make the life of those lucky people easy? Some others are very finicky about it, caring about licenses, restrictions, maturity, etc... and would probably not use a tool like Maven in the first place as it wouldn't allow enough control. So where should we stand? First we should allow the whole gamut of practices, which we do. On one side we're very vigilant about our releases, on the other side our license is extremely liberal for redistributors. So from the start we make either ways possible. Then I happen to think that the distribution channels for *our* (IPMC) projects should be fairly conservative simply because we aim at being at least good open source citizens and I don't see the undocumented distribution of binaries as being part of that. Which I guess marks me finicky :) Matthieu > > Well, I guess one option would be to follow the java.net example and > pollute > the m2-incubator-repository with a bunch of crap and overwrite releases and > add snapshots and stuff. Then they wouldn't want it. :-) > > > Dan > > > > > > thanks, > > dims > > > > On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote: > > >> > Thus: > > >> > If the central maven repository maintainers (Maven PMC) decide to > put > > >> > incubator artifacts into their repository without a click through > > >> > "this is incubator code" disclaimer, we'd have no legal reason to > say > > >> > no. The Apache License allows them to do so. > > >> > > >> The Incubator PMC controls the policy on how podlings release. Not the > > >> upstream policy. And this policy says: "You keep your releases > separated > > >> from the official releases". > > > > > > I'm not disputing that. Currently, podling maven artifacts go to: > > > /www/people.apache.org/repo/m2-incubating-repository > > > and non-podling releases go to: > > > /www/people.apache.org/repo/m2-ibiblio-rsync-repository > > > (which is now a completely inaccurate name :-( Should be > > > m2-release-repository or similar) > > > They are separate. > > > > > > The difference right now is that a non-incubator third party (Maven > PMC) > > > has decided to sync one of those trees into their repository. From > > > what I can see, there is no way an INCUBATOR policy could prevent > another > > > third party from deciding to also sync the other tree in as well. > > > Projects don't release to central. They release to one of the above > > > directories and Maven pulls those into central. (as part of that, the > > > maven team checks the sigs to make sure they are OK, etc...) > > > > > > Another example.... My friend sets up a Nexus repository manager for > > > his users. He adds the incubator repo to the nexus config as he needs > a > > > single thing out of there. Then, any users using my Nexus instance > will > > > get incubator artifacts without setting the incubator repository in > their > > > settings.xml. My friend is a third party, incubator definitely cannot > > > tell him not to do that. > > > > > >> Allowing the usage of a maven repo for > > >> publishing these is a privilege, not a right. > > > > > > OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC > (or > > > RedHat or Debian or CPAN or ....) to not put incubator artifacts in > their > > > repo? Infrastructure probably would have the right if the method maven > > > used caused bandwith issues or similar. Block IP type thing. They do > > > the same thing for "svn abuse". > > > > > > I re-iterate: projects do NOT release to central. They deploy to a > > > project or organization specific location and the MAVEN folks sync that > > > into central if that location meets their requirements and the needs of > > > their users. Basically, do the maven folks "trust" that location to not > > > be full of crap? (and can they trust that the stuff in that repo has a > > > license compatible with putting it in central?) > > > > > > One example of that NOT being the case is the java.net repo. Sun is > > > notoriously bad at putting crap in the repo. Thus, the Maven folks do > > > not sync that repo in anymore. They tried at one point, but it caused > > > too many issues. So they don't now. > > > > > > That's basically why I think the vote is relatively irrelevant. I > voted > > > +1 cause I personally think the "policy" is bad for the incubator and > > > makes it harder for podlings to develop their communities and thus > > > graduate, but I also think the "policy" is completely irrelevant as > it's > > > not enforceable by the Incubator PMC. The Incubator PMC CAN require > the > > > podlings to keep their releases in a separate repo on > people.apache.org, > > > but they cannot require third parties to not sync it into their repos. > > > > > > -- > > > Daniel Kulp > > > [EMAIL PROTECTED] > > > http://www.dankulp.com/blog > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
