Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 37239 invoked from network); 2 Jun 2010 17:26:15 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Jun 2010 17:26:15 -0000 Received: (qmail 53358 invoked by uid 500); 2 Jun 2010 17:26:14 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 53305 invoked by uid 500); 2 Jun 2010 17:26:14 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 53298 invoked by uid 99); 2 Jun 2010 17:26:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 17:26:14 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.213.176] (HELO mail-yx0-f176.google.com) (209.85.213.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 17:26:07 +0000 Received: by yxe42 with SMTP id 42so1175772yxe.35 for ; Wed, 02 Jun 2010 10:25:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.251.8 with SMTP id y8mr8456864ybh.222.1275499546310; Wed, 02 Jun 2010 10:25:46 -0700 (PDT) Received: by 10.151.11.20 with HTTP; Wed, 2 Jun 2010 10:25:46 -0700 (PDT) In-Reply-To: References: <002301cb01c9$4a0e5a60$de2b0f20$@thetaphi.de> Date: Wed, 2 Jun 2010 13:25:46 -0400 Message-ID: Subject: Re: Lucene 2.9.3 ? ( blocking Solr 1.4.1 ? ? ? ) From: Michael McCandless To: dev@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org OK I'm done backporting fixes for 2.9.3/3.0.2... Mike On Tue, Jun 1, 2010 at 4:44 PM, Michael McCandless wrote: > +1 for end-of-day Thu freeze -- I'll finish mine by then. > > But I think for trivial fixes for kinda bad bugs (LUCENE-2311 -- real > bad: mergedSegmentWarner is basically unusable; LUCENE-2356) we should > make an exception (allow them into 2.9.3)? =A0I've already got the patch > up for 2311; I'll do 2356 shortly. > > Mike > > On Tue, Jun 1, 2010 at 4:30 PM, Uwe Schindler wrote: >> Hi all, >> >> I am quite fine with doing a 2.9.3 / 3.0.2 release as soon as possible, = but >> I don't like to force any reopened issues into this release. I have no >> problem with doing this in parallel to the Solr 1.4.1 Release. I don't t= hink >> that it is a good idea, to now reopen a lot of issues, just to get them = into >> 2.9.3 / 3.0.2: >> >> My idea was, to release the current branches as the artifacts for this >> release. Both branches are stable and contain very qualitative branches. >> They contain very stable patches and a release should be very unproblema= tic. >> The testsuites pass easy and I have no problem to create artifacts out o= f >> it. Based on this I said, that I would do the release manager again. I h= ave >> the scripts for the parallel releases upto date and it's easy for me to >> build the release artifacts quickly using JDK 1.5.0_22. >> >> But now starting to forcefully back port issues is not a good idea, so I >> would like to freeze the branches soon and reject patches to go in. I wo= uld >> like to also vote against too late patches to go into these branches. Mi= ke >> did hard work to get lots of recent memory problems in the indexer that = were >> fixed in 3x and trunk branch. But we should not add patches from the lat= e >> developments and for sure no analyzer changes (it's impossible, because = we >> cannot change analyzers because they would change index format. Robert t= old >> me that he does not want to back port any changes here). Next week is >> buzzwords. I would like to start the RC1 shortly after the buzzwords. Si= mon, >> Grant and Robert and me will hopefully have fruitful discussions about i= t, >> but I think we should come to an end very soon. >> >> So I suggest the following timeline: >> I may accept backports in the branches until Thursday evening, so I can >> start to review the branch on Friday. During Buzzwords, we should not co= mmit >> anything and maybe everybody tests the branch and its changes in Solr an= d >> his own installations. If you like I could create pre-artifacts (like a >> Hudson build) on Friday) or maybe RC1. I will also merge changes.txt fil= es >> accorss 2.9, 3.0, 3.x and trunk on Friday. After that I don't want to ac= cept >> any more changes and declare "freeze" on 2.9 and 3.0 branch. >> >> Mark, Hoss: Would it be possible to start the release process of Solr >> together with Lucene's RCs. Would it be possible to *replace" the final >> Lucene artifacts and build the Solr Atifacts together using my builds. S= o we >> would not block each other and maybe we can release on the same day. Thi= s >> would be a good start for future combines Solucene releases :-) >> >> Any comments? >> >> Thanks for all the work. >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: uwe@thetaphi.de >> >>> -----Original Message----- >>> From: Chris Hostetter [mailto:hossman_lucene@fucit.org] >>> Sent: Tuesday, June 01, 2010 8:13 PM >>> To: Lucene Dev >>> Subject: Lucene 2.9.3 ? ( blocking Solr 1.4.1 ? ? ? ) >>> >>> >>> My suggestion that we do a Solr 1.4.1 bug fix seems to have gottne Uwe = and >>> McCandless all excited about doing a Lucene 2.9.3 release... >>> >>> https://issues.apache.org/jira/browse/SOLR-1934 >>> >>> ...but it's not clear to me how realisitc this is, or how close we are = to >> seeing it >>> happen. =A0Beyond hte few issues mentiond in that SOLR issue, is there = a >>> concrete list of issues that are RESOLVED that people want to backport = for >> a >>> 2.9.3 release? >>> >>> I also see quite a few UNRESOLVED issues listed for 2.9.3... >>> >>> https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=3D12310110&= ver >>> sionId=3D12314799&showOpenIssuesOnly=3Dtrue >>> >>> ...are those really blocking a 2.9.3 release, or should we de-classify >> those as >>> "Fix For 2.9.3" issues? >>> >>> >>> -Hoss >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org >>> For additional commands, e-mail: dev-help@lucene.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org >> For additional commands, e-mail: dev-help@lucene.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org