incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <nic...@hedhman.org>
Subject Re: [DISCUSS] Do we really need an incubator?
Date Fri, 18 Jul 2008 08:57:20 GMT
Sorry, for entering this late (too much travel makes it hard to keep
up-to-date)...

On Tue, Jul 8, 2008 at 9:38 PM, William A. Rowe, Jr.
<wrowe@rowe-clan.net> wrote:
> Davanum Srinivas wrote:
>> I doubt we will get much help from the maven team to support this use
>> case. They would rather get the central repo and get it done! What
>> bugs me is that in this whole discussion, no one even mentions how
>> easy it is to add another repo in the poms or the settings.

Well, there is a general Central Repo requirement that you are not
allowed to have <repository> in artifacts deployed to central. Not
sure if someone is ensuring this, but becomes an issue if incubator
artifacts are not mirrored to "central".

> Look, Maven serves packages.  Websites describe projects.  Yes, every
> project dependent on an incubating artifact should provide *website*
> disclaimers that a piece of their project could fall off the earth.

The "fall off the earth" for dependencies is a really weird argument
for end-users. (Which I think Bill is trying to say).

Let's say Apache TLP Flooba depends on Splinka, which is a SF hosted
project. Noone is discussing here that we should have processes
warning users that Splinka may fall off the earth, yet it is just as
likely. Instead (I am convinced) that the user will "depend on" Flooba
community toe deal with that if and when necessary. Sometimes when I
hear this argument of community dissolution, one easily get the
impression that the code vanishes from the planet and a black hole in
my software appears. That is not the case...

So, taking Roy's statement into account of "Incubator Releases are
100% ASF releases", then I see no reason why other projects can't
depend on podlings, why there are disclaimers and being worried that
the user is misled. Example; Felix have a dependency on Jetty. No one
thinks twice about it. Jetty goes into Incubation (now they chose
CodeHaus but could have been here), and suddenly we need to warn
people, disclaimers that Jetty community might fall of the earth, it
is not fully endorsed by ASF and what not. When there is no material
change in code nor community.

The user will make the conscious decision to have his/her own direct
dependency on any project, and if that happens to be an Incubating
project, it happens either from a download via the website
(/dist/incubator/splinka) or via entering
<groupId>org.apache.incubator.splinka</groupId> in the pom.xml.
IMNSHO, all other indirect dependencies are irrelevant, considering
the PMCs fairly strict vetting (making the legal aspect at least as
good as any SF/CodeHaus/Berlios/OW2/... project) of podling releases.
And so on for each level...


While being on the topic; IMHO, podlings that are Sponsored by other
PMCs, expected to become sub-projects there, should all be
fast-tracked through the Incubator. Import -> Vett Legal -> Release ->
Out to TLP. No reason to "educate" the new folks into be able to
sustain a life on their own. The PMC where they are going will be
responsible. If the receiving PMC don't want that, then they should
not Sponsor and we get a natural valve in the intake, and a better
ability to scale as work is distributed out of the Incubator.

Now I crawl back under my seat, put on the life jacket and fly back to
Malaysia. ;o)


Cheers
Niclas

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


Mime
View raw message