On Jul 7, 2008, at 6:59 PM, Davanum Srinivas wrote:

Dan,

Seriously, Can you please give me one concrete  instance where a user
gave up because it was too hard?

It falls into a few situations:
1) Without stuff in the main repo, you cannot do plugins that do things similar to the "mvn jetty:run" and have maven pick them up without wacky changes to your ~/.m2/settings.xml which would then affect all projects.

2) It IS a support burden on the community as people ask "why can't it find it?" even if you document the hell out of it. People tend to not read docs when they expect their tool to work like it always works. Maven people expect to just declare dependencies and have it work. When it doesn't they get frustrated and blame the project for not deploying things correctly and move on.

3) This is the killer one: we did have xfire folks not able to migrate as the corporate firewalls and proxies and such would NOT allow access to people.apache.org. (to be fair, they didn't allow direct access to central either, but their internal repo managers did have access, but only to very limitted repos like central and java.net)

4) A couple of the recent versions of the archetype plugin was unable to create projects from archetypes not available in central. Yes, it was a bug in the plugin, but it affected any archetypes not in central. With mavens < 2.0.9's broken "automatically grab the latest plugin" thing, creating projects from archetypes for anything not in central was impossible. (yes, that was a bug in the plugin and the maven team did fix it fairly quickly, but only incubator projects would have been affected.....)

So yes, there are instances.


Again, Are u stating that removing this restriction would have reduced
the time taken to graduate from 2 years to 1 year?

We'll never know. It certainly affected some of the features we concentrated on and thus may or may not have affected who we could have attracted as committers. It would all be conjecture. I know it DID prevent people migrating from xfire (see above) so I know our user base was lower than it could have been.


We are *NOT* here to rubber stamp external code. Which is what we will become.

Huh? We would be approving proper Apache Incubator releases and making sure the meet Apache legal requirements prior to release. How is that rubber stamping external code?


Basically, IMO, if a release from an incubator project completely meets ALL the legal requirements (none of the "it's ok, fix it for next time" things), it legally can go to central and it should. (also, this means the project needs to have all the CLA's for the imported code, all the LGPL stuff resolved, etc...) Saying incubator releases can only be used in places and with tools that will prompt with a "this is an incubator artifact, us it? y/n" is, IMO, placing a field of use restriction on them which is against our own ideals.

Should maven have a feature that the user can enable to allow various filtering and stuff, certainly. That's a great idea. For users that care, that would be great. Should it be required? IMO, no. The license the artifacts are distributed under doesn't require it and thus, legally, it's not required.


Dan



My feeling is that pmc members are taking their mentor role more
prominence over incubator pmc role which is to make sure we setup
meaningful mechanisms to make sure all aspects are balanced.

In this specific case, a trivial road block has been lifted and
incubator is no longer what it is supposed to be. There are no longer
any checks/balances in the system,

So we should just promote IP Clearance as the primary mechanism and
get existing pmc's or even this PMC to just go ahead and rubber stamp
code and get it over with.

thanks,
dims


On Mon, Jul 7, 2008 at 5:49 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:

On Jul 7, 2008, at 5:09 PM, Davanum Srinivas wrote:

Sorry...Need to take this off my chest before the official VOTE.

Looking at the maven repo thread, begs the question. Do we really need
an incubator?

Isn't it just a IP Clearance SVN now once people have their way with
no distinction at all between incubator and non-incubator code?

What incentives are there left to graduate? How come a little bit of
pain that makes something obvious to end users is such a no-no? Why is
it such a big deal to remove one tiny pebble in their path? A lot of
folks have made it thru...including CXF. gathering users on the merits
of their code/community. It's not like the pebble stopped users from
trying things out. So what's the big deal?

Honestly, I think CXF would have graduated significantly sooner if the central maven repo was used. We specifically did not do a lot of "maven" things (like creating archtypes and such) due to the extra difficulty in using those things. We don't yet use maven for any of the samples/ demos, etc.... It IS a major barrier for a lot people so we didn't concentrate on it. Had the code gone to central, we could have worked on that as well
which would have opened up new opportunities for "mavenites" to get
involved.

So, my question is, if Apache is about "Community over code", why are we putting up barriers to getting the code if that is also creating barriers to building the community? If the code is a proper release (legally OK, etc...), making it hard to use/get hinders the building of the community. Do we like projects taking 2 years to graduate or would we prefer that time
to be shorter?

So, to answer your question: yes, I think the incubator is important. It
does legal vetting, but it also makes sure the communities are acting
proper, learning apache ways, etc.... But the incubator should HELP the
communities grow, not hinder it.

Dan





My 2 cents,

Thanks,
dims

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

---------------------------------------------------------------------
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]





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

---------------------------------------------------------------------
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]

Reply via email to