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