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 <[email protected]> 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)? I'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 <[email protected]> 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 think >> 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 unproblematic. >> The testsuites pass easy and I have no problem to create artifacts out of >> it. Based on this I said, that I would do the release manager again. I have >> 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 would >> like to also vote against too late patches to go into these branches. Mike >> 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 late >> developments and for sure no analyzer changes (it's impossible, because we >> cannot change analyzers because they would change index format. Robert told >> 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. Simon, >> Grant and Robert and me will hopefully have fruitful discussions about it, >> 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 commit >> anything and maybe everybody tests the branch and its changes in Solr and >> 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 files >> accorss 2.9, 3.0, 3.x and trunk on Friday. After that I don't want to accept >> 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. So we >> would not block each other and maybe we can release on the same day. This >> 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: [email protected] >> >>> -----Original Message----- >>> From: Chris Hostetter [mailto:[email protected]] >>> 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. Beyond 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=12310110&ver >>> sionId=12314799&showOpenIssuesOnly=true >>> >>> ...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: [email protected] >>> For additional commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
