incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Date Thu, 18 Sep 2008 17:14:53 GMT
"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.


On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <> 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/
> and non-podling releases go to:
> /www/
> (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 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, but they cannot require
> third parties to not sync it into their repos.
> --
> Daniel Kulp
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Davanum Srinivas ::

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message