"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.
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] > > -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
