Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of cutting@gmail.com designates
 64.233.170.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding:sender;
        b=ZzOXUntn46DT3Y+Ei3jGGkdMDj1dxBoeD5YIvfA6Vcl9PiOEHiJVhJ85PLvEARFK/5
         u6Aw1fWmIi8jlXGNB+cUgt3mZvrik+mMEbmazqkTvVa+DBBVruGoNDTjz/HWzgue70f5
         SUCzjGh8tvgMS1+jDsK0OQuhBKkb7T9/L38nw=
Message-ID: <4938370B.9080002@apache.org>
Date: Thu, 04 Dec 2008 12:01:15 -0800
From: Doug Cutting <cutting@apache.org>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main
 top level searcher classes
References: <285450834.1228332464360.JavaMail.jira@brutus>
	 <57AB459A-5FD8-4F90-8D04-E0EC170A5FEF@apache.org>
 <85d3c3b60812041121p3e4e79a9tb7c1a44c3a37d3e@mail.gmail.com>
In-Reply-To: <85d3c3b60812041121p3e4e79a9tb7c1a44c3a37d3e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Doug Cutting <cutting@gmail.com>

Jason Rutherglen wrote:
> A relatively simple patch such as 1473 Serialization 
> represents this well. 

LUCENE-1473 is an incomplete patch that proposes to commit the project 
to new back-compatibility requirements.  Compatibility requirements 
should not be added lightly, but only deliberately, as they have a 
long-term impact on the ability of the project to evolve.  Prior to this 
we've not heard from folks who require cross-version java serialization 
compatibility.  Without more folks asserting this as a need it is hard 
to rationalize adding this.

> As the 
> internals change frequently and unnannounced the process of developing 
> core patches is difficult and frustrating.

The process is entirely in public.  You have as much announcement as 
anyone.  Patches are weighed on there merits as they are contributed.

> It would benefit the community to focus on the future.  Who exactly is 
> responsible for this?  Which of the committers are building for the 
> future?  Which are doing bug fixes?  What is the process of developing 
> more advanced features in open source?

I've already explained the process several times.

We cannot easily make a long-term plan when we do not have the power to 
assign folks.  We can state long-term goals, like flexible indexing, but 
in the end, it won't get done until someone volunteers to write the 
code.  So you're welcome to start a wish list on the wiki, and you're 
welcome to then start contributing patches that implement items on your 
wish list.  If you propose something that folks think is extremely 
useful, but requires an incompatible change, then it could perhaps be 
done in a branch.  But most of the existing community is interested in 
pushing forward incrementally, trying hard to keep most things 
back-compatible.  If that's too frustrating for you, you can fork Lucene 
and build a new community.

> Right now it seems to be one 
> person, Michael McCandless developing all of the new core code.

Mike does a lot of development, but he also commits a lot of patches 
written by others.

> This is 
> great forward progress, however it's unclear how others can get involved 
> and not get stampeded by the constant changes that all happen via one 
> brilliant person. 

You want Mike to do less?  Others can and do get involved all the time. 
  Look at http://tinyurl.com/5nl78n.  The majority of the things Mike 
works on are instigated by others.

> I have requested of people such as Michael Busch to collaborate on the 
> column stride fields and received no response. 

Did you pay Michael?  No one here is compelled to work with anyone else. 
   We work with others when we feel it is in our mutual self interest.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org