incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Date Wed, 17 Sep 2008 12:12:48 GMT
Guess, you don't get the role of the incubator at all. ah well.

Also, no one here made the argument that the disclaimer is a license
or something for legal protection. So the arguments are moot.

thanks,
-- dims

On Wed, Sep 17, 2008 at 6:57 AM, Daniel Kulp <dkulp@apache.org> wrote:
>
> I voted +1, but I personally think the vote is kind of irrelevant.....
>
> FACT:  The stuff in the incubator repo are Apache releases.   They had the 3
> binding +1 votes from the incubator IPMC members.   They are releases.
>
> FACT: The stuff in the incubator repo is all Apache Licensed artifacts.
>
> FACT: Nowhere in the Apache License is there a requirement that the user has
> to read and accept the Incubator disclaimer prior to use.
>
>
> Given the above:
> If RedHat decided to put incubator artifacts in 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.
>
> If Debian decided to put incubator artifacts in 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.
>
> If the CPAN maintainers decided to put incubator perl modules 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.
>
> If repo maintainer XXXXX decided to put incubator perl modules 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.
>
> If Ivy/Builder/Ant/etc.... decided to create their own repository and wanted
> the incubator artifacts in it,  we'd have no legal reason to say no.   The
> Apache License allows them to do so.
>
> 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.
>
>
> Thus, to me, the vote is kind of pointless.  Jukka (or other maven users)
> should just ask the Maven folks to start syncing the m2-incubator-repo dir
> off of people.apache.org.   If the Maven PMC thinks that's in the best
> interest of THEIR community and users, they should go ahead and do it
> (obviously working with infrastructure to work out logistics to reduce load
> and such).   The license that applies to all the artifacts in that repo
> certainly allows it.
>
>
> Thus, this vote really is about reducing the burden on the Maven PMC and on
> infrastructure.   There is an auto-sync dir already setup.   Should we use it
> or should they be separate which would require new syncs setup which would
> result in more processes/connections on people.apache.org, extra bandwidth
> used for those extra rsyncs,  etc....
>
> If the incubator wants to go off to the board and legal and ask for a
> new "Apache Incubator License" that would require the click through, fine.
> But until then, lets actually follow the license that is currently being
> used.
>
> Anyway, thats my 2 cents worth.  (caveat: it may not be worth 2 cents to you)
>
> :-)
>
> Dan
>
>
>
>
>
> On Tuesday 16 September 2008 6:49:04 pm Matthieu Riou wrote:
>> On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
>>
>> <wrowe@rowe-clan.net>wrote:
>> > Justin Erenkrantz wrote:
>> >> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny
>> >> <elecharny@gmail.com>
>> >>
>> >> wrote:
>> >>> Craig L Russell wrote:
>> >>>> -1
>> >>>>
>> >>>> I believe that allowing incubating releases to be treated as full
>> >>>> Apache releases diminishes the Apache brand and makes incubation
>> >>>> disclaimers moot.
>> >>>>
>> >>>> With Maven, it is too easy to depend on a release with transitive
>> >>>> dependencies on incubating releases without even knowing it. When
the
>> >>>> incubating release subsequently is abandoned, blame will be cast
>> >>>> widely, including Apache itself.
>> >>>>
>> >>>> Considering that dependencies on incubating releases can be resolved
>> >>>> by explicitly adding an incubating Maven repository into your
>> >>>> settings, I don't
>> >>>> think that wide, mirrored, distribution is warranted.
>> >>>>
>> >>>> Craig
>> >>>
>> >>> -1 too, for the same reasons.
>> >>
>> >> -1.  Craig pointed out my objections as well.  -- justin
>> >
>> > Just so everyone understands this in context, the objection above is moot
>> > because...
>> >
>> > ...maven is a package deployment mechanism
>>
>> Beg your pardon? I know that the homepage casts a wide net ("Maven is a
>> software project management and comprehension tool.") but in my book Maven
>> is used to build stuff (which happens to be almost exclusively Java). I
>> don't know of anybody who goes to actual users and tell them "here you go,
>> unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
>> execute 'mvn install' and once all test cases pass you're golden".
>>
>> Maven is a build tool. Users don't build, developers do. And developers
>> should know about licenses and disclaimers.
>>
>> Cheers,
>> Matthieu
>>
>> > ...developers who determine what to bundle into their package don't spend
>> >   a whole lot of time explaining to users that something within their
>> >   package is 'incubating' code, or 'patched/forked' code, or virgin
>> >   original code
>> >
>> > ...the developer who deploys an app is either going to explain it
>> > contains an incubating artifact to their users, or they won't
>> >
>> > ...no matter if the developer bundles an incubating jar, or calls it up
>> >   out of maven...
>> >
>> > The user has ***exactly*** the same experience.
>> >
>> > Presenting a user with a dialog "Package FOO requires the BAR.jar, an
>> > Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
>> > disclaimer" will leave them utterly befuddled and is entirely worthless
>> > information in the context that they install package FOO (nevermind that
>> > the "actual" disclaimer appears to be non-existent in our release
>> > documentation).
>> >
>> > We permit GPL, commercial, virtual anything to be deposited into Maven
>> > if I understand correctly.  WTF not incubation artifacts, in that light?
>> >
>> > Bill
>> >
>> > [1] alternately... "is a tasty beverage container"
>> > [2]
>> > http://incubator.apache.org/guides/releasemanagement.html#notes-disclaime
>> >r
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message