Hi, -1 on the current VOTE, as I am thinking the same like Michael Busch and Bill Au:
- I am fine with merging development mailing lists (not user mailing lists). - But I do not want to enforce releases to appear at the same time, so there must be some coordination with the fact that "Solr depends on Lucene but NOT Lucene depends on Solr". - A modularization is needed: Lucene-Core (with no analyzers at all, only abstract classes), Lucene-Analysis, Lucene-Facetting, Lucene-FunctionQueries, Lucene-Foobar, Solr-Core, Solr-Foobar,... - No requirement for Lucene Committers to work on Solr Tests or that Solr tests must pass when Lucene Changes. I would like to have it more in a way that the issue tracker would do that like it is now: Lucene is enhanced, BW layer still alive (so solr tests should work), so open issue against solr referring to lucene issue to fix solr and remove usage of deprecated methods or fix other problems. - And last but not least the whole merge should be done *after* the current code bases are again closer to each other, especially Flex is in and Solr is at least on Lucene 3.0.1. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Michael Busch [mailto:[email protected]] > Sent: Thursday, March 04, 2010 4:13 AM > To: [email protected] > Subject: Re: [VOTE] merge lucene/solr development > > On 3/3/10 6:00 PM, Yonik Seeley wrote: > > On Wed, Mar 3, 2010 at 8:10 PM, Michael Busch<[email protected]> > wrote: > > > >> So if it seems like that most people are concerned about releases > (even > >> those you are generally in favor of this proposal), then maybe we > should > >> discuss exactly this point. We haven't really discussed alternatives > about > >> the release alignment. This vote feels rushed. > >> > > It's been discussed for a week, and I'm with Mark - I'm only for a > > real merge of development, and that includes release schedules. > > > > -Yonik > > > > > > How will we merge release policies? (or are they exactly the same?) > Does > Solr use the same release numbering? Does it have the same > backwards-compatibility requirements as Lucene? > > If we release Solr 1.5.0 with Lucene 3.1.0, and we find a bug in the > Lucene jar and want to release a 3.1.1 bugfix release, will we also > release a Solr 1.5.1, even though all Solr jars would be identical to > the 1.5.0? > Or will we just release Solr/Lucene 4.0.0 next and always use same > release numbers? > > How will we avoid longer release cycles? Solr had had very infrequent > releases. What were the reasons for that? Are we comfortable with > saying > we'll just try to be disciplined enough or is there a way to somehow > enforce release frequency? It seems certain that if more people work on > the code, there will at any given point be more patches/new features > under development and things need to be coordinated in a way that > allows > frequent releases. > > In an earlier mail I gave the following example: If we had a separate > analyzer module, and we add an analyzer in a new language to it, it > would be cool to release it soon, without having to wait until > Lucene/Solr are ready for a release. The pace here can be faster, > because I imagine in such an Analyzer module it's much less common that > a patch "touches everything". What do people think about this? Maybe > it's just a nice wish, but not realizable, because there'd be a lot of > version management overhead. But maybe not? > > I'm not against this whole thing and I'm not trying to be difficult > here, and I dislike endless discussions just as everyone else. But I > honestly don't know right now how to vote, because I have those open > questions and know that a lot of other people here are concerned about > the release alignment as well. > > Michael
