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]
