Are you arguing for no change Yonik? I agree with all of your points in
any case.
What appeals to me most so far is:
Take the best of contrib and up its status to something like "modules".
Equal to core, different requirements, dependencies, etc. Perhaps take
queryparser out of core, but frankly I'd wouldn't mind just leaving core
as it is.
Reintroduce the sandbox (I believe core was sandbox, part of the lower
bar history) and put lesser contrib there and new stuff thats unproven.
Contrib doesn't appeal to me as a name anyway.
That would give core, modules, and the sandbox (perhaps sandbox is a
module?). Things could move from sandbox to core or the modules. Modules
get new requirements similar to core - back compat guarantees and
changes.txt per module.
Yonik Seeley wrote:
On Mon, Mar 23, 2009 at 11:10 AM, Michael McCandless
<luc...@mikemccandless.com> wrote:
4. Move contrib/* under src/java/*, updating the javadocs to state
back compatibility promises per class/package.
- contrib has always had a lower bar and stuff was committed under
that lower bar - there should be no blanket promotion.
- contrib items may have different dependencies... putting it all
under the same source root can make a developers job harder
- many contrib items are less related to lucene-java core indexing and
searching... if there is no contrib, then they don't belong in the
lucene-java project at all.
- right now it's clear - core can't have dependencies on non-core
classes. If everything is stuck in the same source tree, that goes
away.
I think there are a lot of benefits to continue considering very
carefully if something is "core" or not.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
