Peter Carlson wrote: >Hi Brian, > >I have a suggestions that would be a little different, but I think would >accomplish the same function. I was looking at the current Jakarta CVS >repositories and it looks like we might create a sublevel under >Jakarta-lucene. > >Right now the CVS repository looks like > >/jakarta-lucene/docs >/jakarta-lucene/xdocs >/jakarta-lucene/src >/jakarta-lucene/lib >... > > >What about >/jakarta-lucene/contrib/docs >/jakarta-lucene/contrib/xdocs >/jakarta-lucene/contrib/src >/jakarta-lucene/lib >/jakarta-lucene/scratchpad/docs >/jakarta-lucene/scratchpad/xdocs >/jakarta-lucene/scratchpad/src >/jakarta-lucene/lucene/docs >/jakarta-lucene/lucene/xdocs >/jakarta-lucene/lucene/src >... > > >This way if you wanted to just cvs to get the core lucene build you can >point to /jarkarta-lucene/lucene/... Instead of jarkarta-lucene/... > Sounds good. Maybe /jakarta-lucene/core or main instead? But either way, I like it. +1.
> > >Thoughts anyone > >--Peter > > >------------------------------------------------------------------------ > > >On 3/26/02 11:00 AM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: > >>>1) Create a contributions area as part of the Lucene CVS. This area would be >>>used to bring together submitted to the Lucene mailing list (with permission >>>from the submitter). The code would need to be repackaged (i.e. Give it an >>>org.apache.lucene.contrib package), licensed (add the apache license), added >>>to the "build-contrib" target of the ant build script. >>> >>>There are a lot of great contributions out there that may or may not become >>>part of Lucene's core build. I am +1 and am willing to set this up and help >>>maintain it. >>> >>I prefer instead to have the /contrib area a separate CVS repo. My >>experience in other OS projects is that (a) contrib areas rapidly get >>to be larger than then main distribution, making downloads slower, and >>(b) often get out of sync with the main distribution. The result is >>that a mix of core code and contributions of varying levels of >>quality, completedness, and maintainedness tends to lower the perceived >>level of quality of the distribution. >> >>So +1 for a /contrib area, -1 for making it part of the main CVS repo >>and distribution. >> >>>2) Create a scratchpad area in the Lucene CVS >>>(org.apache.lucene.scratchpad). This area would be focused on creating new >>>parts of the Lucene core in an experimental mode. This code would be >>>considered unstable and unsupported. If a part becomes stable and is desired >>>to be moved into the Lucene core build, it must be approved through a >>>committers vote (+3 votes). >>> >>Again, -1 if this is part of the main CVS repo, +1 on the concept. >> >>>3) Adopt a more formal release plan. >>> a)Beta means feature freeze >>> b)Release candidate means code freeze (unless bugs) >>>To move into a beta or release candidate stage, you must a vote by the >>>committers (+3 votes). >>> >>+1 >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
