Peter Carlson wrote: >Hi all committers, > >Here are some questions to vote on. If you don't like or understand the >description, please vote -1, if you don't care vote 0, if you like the idea >and would be willing to contribute some time please vote +1 > >Each item below needs +3 items to vote with no -1 votes to pass. > > >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. > +1. Given other's feedback, I think the best way to handle this might be to store these as simply tars or zips with some release notes by the original contributor. This way they do not have to be built (and compatibility maintained as the code evolves), and yet they are available to those who have a need and a willing to experiment and maybe adapt them to the use with Lucene in their project (if such adaptation becomes needed over time). The major benefits over a simple list of links to other pages is that (a) once contributed these resources remain available to anyone interested, and (b) people without ability to host their own download sites can still contribute (I know, I am one!).
> > > >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). > >This area would be a place that committers can join together on new projects >/ experiments so they do not interfere with the regular Lucene development >process and still get collaboration. > >My vote is 0 for this area. I think its a good idea, but I don't have any >current plans to help with it. > +1. I think this is a great idea! As far as details, I'm 0 on build target or no build target (just don't know what are the pluses or minuses of this), except maybe this: what happens if the people involved in one sub-effort under the scratchpad area loose interest for a month, and meanwhile the main codebase evolves such that that scratchpad sub-effort area no longer compiles? I think a good answer to this is that pieces of scratchpad can be tarred up and moved into "contrib" area if active development stops on them. And viceversa, projects on the "contrib" area that people want to make current and bring up to speed can be untarred and inserted into the "scratchpad" for common hacking and preparation for inclusion into the main codeline. The main benefit I see here is a place for people to collaborate on code without affecting others until ready. A kind of a branch without a branch. One question - can commit access to this area be controlled separately? If not, I'm still +1, but it might be nice. > > >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). > >I am willing to help with the build process. I will work with Doug to help >handle these activities. This also would include updating the web site. > >I am +1. > +1, but I won't be able to help here at this time. Dmitry Serebrennikov -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
