On Mon, Nov 1, 2010 at 10:59 PM, Grant Ingersoll <[email protected]>wrote:
> I'm not sure I would word it that way. A few years is a long time. In the > span of two years Lucene has seen improvements of upwards of 10-50x in terms > of indexing and search speed. You simply never know where innovation is > coming from. This is why you have branches such as trunk, 1.X, etc. and you > back port, but to say we will be on 1.x for years to come is a very bad > thing, IMO. > Yes, and Lucene has always had a clear identity: it's a text indexing and search engine. It set a clear expectation for what it is (and isn't) going to do and then delivered. As much as there's a risk in defining a project's scope and standard narrowly, there's risk in being too loose. I tend to believe the latter is a slightly larger risk now. Would I rather have half of 3 more algorithms, or more polish on 3 existing ones? More polish. By all means, once things are polished, 1.0 is out, let's let anyone pile in innovations for a loose road map for 1.1, 1.2, 2.0 -- a plan around which organizations rather than individual hobbyists like me can rally and plan and begin to depend. I think the free-for-all approach is just fine for 0.x and think it's fine to stay in that mode as long as it takes -- it's kind of the definition of "0.x" and I am trying to articulate what it is that "1.x" means that's different. What is it? > Hmmm. I hope no one just decides they think they know what they can throw > away. I'm all for deprecation, but to me deprecation is about changes to > APIs. I don't know that we should throw away algorithms. People can simply > choose not to use them. Open source is evolutionary, not revolutionary. > Sometimes it just takes a while for people to realize it is useful to them. > Does that mean we should never throw things away? Of course not. It just > means we need to think about and discuss it. > Of course, nobody would delete things without discussion. I think an 'attic' concept is fine for this too. I'm not talking about removing code because it's old but possibly useful, but because it's not finished, documented, tested, or consistent with newer code, and has no foreseeable hope of it. Once we get to "1.0", everything is implicitly blessed as "all this code is on purpose and we're going to support this for a while". I think we want to be able to believe that by 1.0. Not meeting that promise has negative consequence just as retiring something that someone might used sometime. > I don't agree we should "aggressively" turn away code. It simply isn't how > open source works. Community over code. There is no crystal ball here and > you simply never know where the next good idea is going to come from unless > you let things ruminate. We may not commit it right away or we may > encourage the contributor to flesh it out more, but turn away is not the > right attitude, IMO. Open source is about scratching your itch and it's > about innovation coming from the seeming middle of nowhere. Does that > introduce some chaos? Yes. Does it make for better code in the long run? > Absolutely. > > I accept the point but want to argue the other side since I don't hear enough of the counter-argument. Apache doesn't let anyone commit any code they like, community or no. So there must be a point on the spectrum between accepting anything and accepting nothing we have to find. I only happen to think we will need to have a stronger bias towards wanting coherent, tested, documented code coming in as the project evolves. Not now if you like -- but by "1.0", or else what does that mean? Ruminations remain fine. We have patches and branches and still ample wiggle room to commit and collaborate iteratively in HEAD between releases. I just think you get what you ask for in a case like this. if bits of ideas are accepted into the project, we'll end up with lots of people's bits. If the bar is higher for quality and consistent, I believe people do match the standard they see and hit that bar. We're already talking about people who want to do what it takes to contribute something. Community is the reason I think this. I assert that a bit more standards, review and roadmap actually attracts more community in the long run. I'm thinking of big organizations. Can you picture your Twitters of the world using this? kind of, bits, in a maintained branch, with local modifications, yes. (In fact I think we know of a few big organizations using it kind of like this.) That's fine for now but something I think must change before you can picture it being used as-is, for the most part. And that's the something that's between here and 1.x that I'm trying to articulate. Otherwise I don't know what difference there is between 0.4, 0.5, 0.6, 1.0, 2.0?
