Re: 4.1 release notes: please review
Sorry for the delay Steve, i was on the run .. thanks for updating the Notes :) Stefan On Sunday, January 20, 2013 at 3:19 PM, Steve Rowe wrote: Stefan, I've gone ahead and incorporated your changes into the release note. Thanks, Steve On Jan 17, 2013, at 12:43 PM, Steve Rowe sar...@gmail.com (mailto:sar...@gmail.com) wrote: Thanks Stefan, can you go ahead and make these modifications? I like the priority sorting you suggested, though I haven't completely done that everywhere else. - Steve On Jan 17, 2013, at 6:42 AM, Stefan Matheis matheis.ste...@gmail.com (mailto:matheis.ste...@gmail.com) wrote: Hey Steve just a quick note about the admin ui section in solr's notes, i would drop Replication Icon on Dashboard now reflects Master-/Slave- State because it suggests a bigger change than it really is/was .. there is no new functionality included, it really just shows the right icon (it was not wrong before, we used a generic icon before) On the other hand, i suggest we include a note for SOLR-3876 (Solr Admin UI is completely dysfunctional on IE 9) which is fixed in 4.1, which is really worth mentioning it :) Don't know if the other list is sorted by priority (or what ever you'd like to name it), if so .. i would sort it like this: Admin UI improvements: * Works now also while using Internet Exploder (or something like this?) * Enhanced readability of XML query response display in Query UI * Many improvements to DataImportHandler UI * Core creation and deletion now updates the main/left list of cores * Admin Cores UI now redirects to newly created core details * Deleted documents are calculated/displayed. * Allow multiple Items to stay open on Plugins-Page Stefan On Thursday, January 17, 2013 at 8:26 AM, Steve Rowe wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
Stefan, I've gone ahead and incorporated your changes into the release note. Thanks, Steve On Jan 17, 2013, at 12:43 PM, Steve Rowe sar...@gmail.com wrote: Thanks Stefan, can you go ahead and make these modifications? I like the priority sorting you suggested, though I haven't completely done that everywhere else. - Steve On Jan 17, 2013, at 6:42 AM, Stefan Matheis matheis.ste...@gmail.com wrote: Hey Steve just a quick note about the admin ui section in solr's notes, i would drop Replication Icon on Dashboard now reflects Master-/Slave- State because it suggests a bigger change than it really is/was .. there is no new functionality included, it really just shows the right icon (it was not wrong before, we used a generic icon before) On the other hand, i suggest we include a note for SOLR-3876 (Solr Admin UI is completely dysfunctional on IE 9) which is fixed in 4.1, which is really worth mentioning it :) Don't know if the other list is sorted by priority (or what ever you'd like to name it), if so .. i would sort it like this: Admin UI improvements: * Works now also while using Internet Exploder (or something like this?) * Enhanced readability of XML query response display in Query UI * Many improvements to DataImportHandler UI * Core creation and deletion now updates the main/left list of cores * Admin Cores UI now redirects to newly created core details * Deleted documents are calculated/displayed. * Allow multiple Items to stay open on Plugins-Page Stefan On Thursday, January 17, 2013 at 8:26 AM, Steve Rowe wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
A lot of stuff in a short time! I know it is a Lucene feature, but the fact that Solr now compresses stored fields is significant to Solr users, and IMO should be included in the Solr release notes. Upayavira On Thu, Jan 17, 2013, at 07:40 AM, Shai Erera wrote: +1 Shai On Thu, Jan 17, 2013 at 9:26 AM, Steve Rowe [1]sar...@gmail.com wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: [2]http://wiki.apache.org/solr/ReleaseNote41 Lucene: [3]http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: [4]dev-unsubscr...@lucene.apache.org For additional commands, e-mail: [5]dev-h...@lucene.apache.org References 1. mailto:sar...@gmail.com 2. http://wiki.apache.org/solr/ReleaseNote41 3. http://wiki.apache.org/lucene-java/ReleaseNote41 4. mailto:dev-unsubscr...@lucene.apache.org 5. mailto:dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
Hey Steve just a quick note about the admin ui section in solr's notes, i would drop Replication Icon on Dashboard now reflects Master-/Slave- State because it suggests a bigger change than it really is/was .. there is no new functionality included, it really just shows the right icon (it was not wrong before, we used a generic icon before) On the other hand, i suggest we include a note for SOLR-3876 (Solr Admin UI is completely dysfunctional on IE 9) which is fixed in 4.1, which is really worth mentioning it :) Don't know if the other list is sorted by priority (or what ever you'd like to name it), if so .. i would sort it like this: Admin UI improvements: * Works now also while using Internet Exploder (or something like this?) * Enhanced readability of XML query response display in Query UI * Many improvements to DataImportHandler UI * Core creation and deletion now updates the main/left list of cores * Admin Cores UI now redirects to newly created core details * Deleted documents are calculated/displayed. * Allow multiple Items to stay open on Plugins-Page Stefan On Thursday, January 17, 2013 at 8:26 AM, Steve Rowe wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
On Thu, Jan 17, 2013 at 10:45 AM, Upayavira u...@odoko.co.uk wrote: I know it is a Lucene feature, but the fact that Solr now compresses stored fields is significant to Solr users, and IMO should be included in the Solr release notes. I fixed the release year for Solr release notes and added a few lines about the improvements brought by the new Lucene 4.1 codec. -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: 4.1 release notes: please review
I added the important URL-encoding issue tot he Solr release notes. There was again a question on solr-user that Solr does not decode URLs correctly (because user missed to configure Tomcat correctly). With 4.1 this is now obsolete and works out of the box with any web container, so this is really important to mention. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 8:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: 4.1 release notes: please review
Steve, This is pretty longwinded and maybe just the first sentence will suffice with see the wiki for more information. All of this is documented there, more or less. None of this will affect very many people. -- The DataImportHandler contrib module has some minor backwards-compatibility breaks in this release. 1. Both NumberFormatTransformer DateFormatTransformer default to the root locale if none is specified. Prior versions used the JVM default locale. It is strongly advised that users always specify the locale when using this transformer. See https://issues.apache.org/jira/browse/SOLR-4095 2. Both FileDataSoruce and FieldReaderDataSource default to UTF-8 encoding if none is specified. Prior versions used the JVM default. See https://issues.apache.org/jira/browse/SOLR-4096 . Also, the behavior of DataSource and encoding may change again in a subsequent release. See https://issues.apache.org/jira/browse/SOLR-2347 . 3. The formatDate evaluator now defaults to using the root locale. Prior versions used the JVM default. Both the locale timezone now can be specified using new optional parameters. See https://issues.apache.org/jira/browse/SOLR-4086 https://issues.apache.org/jira/browse/SOLR-2201 . 4. The dataimport.properties file, which holds the last indexed timestamp for use with delta imports, is now by default using the root locale. This default can be overridden using the new propertyWriter / tag in data-config.xml. Prior versions used the default JVM locale. This is only of concern if your default locale uses different DataFormatSymbols than the root locale and if your installation depends on these alternate symbols (for instance if your RDMBS takes dates using your locale-specific date symbols). See https://issues.apache.org/jira/browse/SOLR-4051 5. The experimental DIHProperties interface has changed, and is now an abstract class. This will require code changes for anyone who has a custom DIHProperties. Also note that future API changes with this class are possible in subsequent releases. See https://issues.apache.org/jira/browse/SOLR-4051 6. The Evaluator framework has received extensive refactoring. Some custom evaluators may require code changes. Specifically, public or protected methods from the EvaluatorBag class have been moved to the Evaluator abstract class that all Evalutators must extend. See https://issues.apache.org/jira/browse/SOLR-4086 -- James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 1:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
Hi James, Please go ahead edit the wiki page - I'm sure you'll do a better job of summarizing these than me. Steve On Jan 17, 2013, at 11:31 AM, Dyer, James james.d...@ingramcontent.com wrote: Steve, This is pretty longwinded and maybe just the first sentence will suffice with see the wiki for more information. All of this is documented there, more or less. None of this will affect very many people. -- The DataImportHandler contrib module has some minor backwards-compatibility breaks in this release. 1. Both NumberFormatTransformer DateFormatTransformer default to the root locale if none is specified. Prior versions used the JVM default locale. It is strongly advised that users always specify the locale when using this transformer. See https://issues.apache.org/jira/browse/SOLR-4095 2. Both FileDataSoruce and FieldReaderDataSource default to UTF-8 encoding if none is specified. Prior versions used the JVM default. See https://issues.apache.org/jira/browse/SOLR-4096 . Also, the behavior of DataSource and encoding may change again in a subsequent release. See https://issues.apache.org/jira/browse/SOLR-2347 . 3. The formatDate evaluator now defaults to using the root locale. Prior versions used the JVM default. Both the locale timezone now can be specified using new optional parameters. See https://issues.apache.org/jira/browse/SOLR-4086 https://issues.apache.org/jira/browse/SOLR-2201 . 4. The dataimport.properties file, which holds the last indexed timestamp for use with delta imports, is now by default using the root locale. This default can be overridden using the new propertyWriter / tag in data-config.xml. Prior versions used the default JVM locale. This is only of concern if your default locale uses different DataFormatSymbols than the root locale and if your installation depends on these alternate symbols (for instance if your RDMBS takes dates using your locale-specific date symbols). See https://issues.apache.org/jira/browse/SOLR-4051 5. The experimental DIHProperties interface has changed, and is now an abstract class. This will require code changes for anyone who has a custom DIHProperties. Also note that future API changes with this class are possible in subsequent releases. See https://issues.apache.org/jira/browse/SOLR-4051 6. The Evaluator framework has received extensive refactoring. Some custom evaluators may require code changes. Specifically, public or protected methods from the EvaluatorBag class have been moved to the Evaluator abstract class that all Evalutators must extend. See https://issues.apache.org/jira/browse/SOLR-4086 -- James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 1:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: 4.1 release notes: please review
Do you think it is appropriate that we put all of this in a section in the release notes, or something more succinct? James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 10:36 AM To: dev@lucene.apache.org Subject: Re: 4.1 release notes: please review Hi James, Please go ahead edit the wiki page - I'm sure you'll do a better job of summarizing these than me. Steve On Jan 17, 2013, at 11:31 AM, Dyer, James james.d...@ingramcontent.com wrote: Steve, This is pretty longwinded and maybe just the first sentence will suffice with see the wiki for more information. All of this is documented there, more or less. None of this will affect very many people. -- The DataImportHandler contrib module has some minor backwards-compatibility breaks in this release. 1. Both NumberFormatTransformer DateFormatTransformer default to the root locale if none is specified. Prior versions used the JVM default locale. It is strongly advised that users always specify the locale when using this transformer. See https://issues.apache.org/jira/browse/SOLR-4095 2. Both FileDataSoruce and FieldReaderDataSource default to UTF-8 encoding if none is specified. Prior versions used the JVM default. See https://issues.apache.org/jira/browse/SOLR-4096 . Also, the behavior of DataSource and encoding may change again in a subsequent release. See https://issues.apache.org/jira/browse/SOLR-2347 . 3. The formatDate evaluator now defaults to using the root locale. Prior versions used the JVM default. Both the locale timezone now can be specified using new optional parameters. See https://issues.apache.org/jira/browse/SOLR-4086 https://issues.apache.org/jira/browse/SOLR-2201 . 4. The dataimport.properties file, which holds the last indexed timestamp for use with delta imports, is now by default using the root locale. This default can be overridden using the new propertyWriter / tag in data-config.xml. Prior versions used the default JVM locale. This is only of concern if your default locale uses different DataFormatSymbols than the root locale and if your installation depends on these alternate symbols (for instance if your RDMBS takes dates using your locale-specific date symbols). See https://issues.apache.org/jira/browse/SOLR-4051 5. The experimental DIHProperties interface has changed, and is now an abstract class. This will require code changes for anyone who has a custom DIHProperties. Also note that future API changes with this class are possible in subsequent releases. See https://issues.apache.org/jira/browse/SOLR-4051 6. The Evaluator framework has received extensive refactoring. Some custom evaluators may require code changes. Specifically, public or protected methods from the EvaluatorBag class have been moved to the Evaluator abstract class that all Evalutators must extend. See https://issues.apache.org/jira/browse/SOLR-4086 -- James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 1:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
My take on release notes is that they mainly talk about new features/big changes, and if other things are mentioned, they are only mentioned briefly. But if you think it's worth its own section, go for it. Steve On Jan 17, 2013, at 11:47 AM, Dyer, James james.d...@ingramcontent.com wrote: Do you think it is appropriate that we put all of this in a section in the release notes, or something more succinct? James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 10:36 AM To: dev@lucene.apache.org Subject: Re: 4.1 release notes: please review Hi James, Please go ahead edit the wiki page - I'm sure you'll do a better job of summarizing these than me. Steve On Jan 17, 2013, at 11:31 AM, Dyer, James james.d...@ingramcontent.com wrote: Steve, This is pretty longwinded and maybe just the first sentence will suffice with see the wiki for more information. All of this is documented there, more or less. None of this will affect very many people. -- The DataImportHandler contrib module has some minor backwards-compatibility breaks in this release. 1. Both NumberFormatTransformer DateFormatTransformer default to the root locale if none is specified. Prior versions used the JVM default locale. It is strongly advised that users always specify the locale when using this transformer. See https://issues.apache.org/jira/browse/SOLR-4095 2. Both FileDataSoruce and FieldReaderDataSource default to UTF-8 encoding if none is specified. Prior versions used the JVM default. See https://issues.apache.org/jira/browse/SOLR-4096 . Also, the behavior of DataSource and encoding may change again in a subsequent release. See https://issues.apache.org/jira/browse/SOLR-2347 . 3. The formatDate evaluator now defaults to using the root locale. Prior versions used the JVM default. Both the locale timezone now can be specified using new optional parameters. See https://issues.apache.org/jira/browse/SOLR-4086 https://issues.apache.org/jira/browse/SOLR-2201 . 4. The dataimport.properties file, which holds the last indexed timestamp for use with delta imports, is now by default using the root locale. This default can be overridden using the new propertyWriter / tag in data-config.xml. Prior versions used the default JVM locale. This is only of concern if your default locale uses different DataFormatSymbols than the root locale and if your installation depends on these alternate symbols (for instance if your RDMBS takes dates using your locale-specific date symbols). See https://issues.apache.org/jira/browse/SOLR-4051 5. The experimental DIHProperties interface has changed, and is now an abstract class. This will require code changes for anyone who has a custom DIHProperties. Also note that future API changes with this class are possible in subsequent releases. See https://issues.apache.org/jira/browse/SOLR-4051 6. The Evaluator framework has received extensive refactoring. Some custom evaluators may require code changes. Specifically, public or protected methods from the EvaluatorBag class have been moved to the Evaluator abstract class that all Evalutators must extend. See https://issues.apache.org/jira/browse/SOLR-4086 -- James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 1:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
Thanks Stefan, can you go ahead and make these modifications? I like the priority sorting you suggested, though I haven't completely done that everywhere else. - Steve On Jan 17, 2013, at 6:42 AM, Stefan Matheis matheis.ste...@gmail.com wrote: Hey Steve just a quick note about the admin ui section in solr's notes, i would drop Replication Icon on Dashboard now reflects Master-/Slave- State because it suggests a bigger change than it really is/was .. there is no new functionality included, it really just shows the right icon (it was not wrong before, we used a generic icon before) On the other hand, i suggest we include a note for SOLR-3876 (Solr Admin UI is completely dysfunctional on IE 9) which is fixed in 4.1, which is really worth mentioning it :) Don't know if the other list is sorted by priority (or what ever you'd like to name it), if so .. i would sort it like this: Admin UI improvements: * Works now also while using Internet Exploder (or something like this?) * Enhanced readability of XML query response display in Query UI * Many improvements to DataImportHandler UI * Core creation and deletion now updates the main/left list of cores * Admin Cores UI now redirects to newly created core details * Deleted documents are calculated/displayed. * Allow multiple Items to stay open on Plugins-Page Stefan On Thursday, January 17, 2013 at 8:26 AM, Steve Rowe wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: 4.1 release notes: please review
Ok I have it in the wiki in its own section but I condensed it. Feel free to edit further as you desire. James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 10:59 AM To: dev@lucene.apache.org Subject: Re: 4.1 release notes: please review My take on release notes is that they mainly talk about new features/big changes, and if other things are mentioned, they are only mentioned briefly. But if you think it's worth its own section, go for it. Steve On Jan 17, 2013, at 11:47 AM, Dyer, James james.d...@ingramcontent.com wrote: Do you think it is appropriate that we put all of this in a section in the release notes, or something more succinct? James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 10:36 AM To: dev@lucene.apache.org Subject: Re: 4.1 release notes: please review Hi James, Please go ahead edit the wiki page - I'm sure you'll do a better job of summarizing these than me. Steve On Jan 17, 2013, at 11:31 AM, Dyer, James james.d...@ingramcontent.com wrote: Steve, This is pretty longwinded and maybe just the first sentence will suffice with see the wiki for more information. All of this is documented there, more or less. None of this will affect very many people. -- The DataImportHandler contrib module has some minor backwards-compatibility breaks in this release. 1. Both NumberFormatTransformer DateFormatTransformer default to the root locale if none is specified. Prior versions used the JVM default locale. It is strongly advised that users always specify the locale when using this transformer. See https://issues.apache.org/jira/browse/SOLR-4095 2. Both FileDataSoruce and FieldReaderDataSource default to UTF-8 encoding if none is specified. Prior versions used the JVM default. See https://issues.apache.org/jira/browse/SOLR-4096 . Also, the behavior of DataSource and encoding may change again in a subsequent release. See https://issues.apache.org/jira/browse/SOLR-2347 . 3. The formatDate evaluator now defaults to using the root locale. Prior versions used the JVM default. Both the locale timezone now can be specified using new optional parameters. See https://issues.apache.org/jira/browse/SOLR-4086 https://issues.apache.org/jira/browse/SOLR-2201 . 4. The dataimport.properties file, which holds the last indexed timestamp for use with delta imports, is now by default using the root locale. This default can be overridden using the new propertyWriter / tag in data-config.xml. Prior versions used the default JVM locale. This is only of concern if your default locale uses different DataFormatSymbols than the root locale and if your installation depends on these alternate symbols (for instance if your RDMBS takes dates using your locale-specific date symbols). See https://issues.apache.org/jira/browse/SOLR-4051 5. The experimental DIHProperties interface has changed, and is now an abstract class. This will require code changes for anyone who has a custom DIHProperties. Also note that future API changes with this class are possible in subsequent releases. See https://issues.apache.org/jira/browse/SOLR-4051 6. The Evaluator framework has received extensive refactoring. Some custom evaluators may require code changes. Specifically, public or protected methods from the EvaluatorBag class have been moved to the Evaluator abstract class that all Evalutators must extend. See https://issues.apache.org/jira/browse/SOLR-4086 -- James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -Original Message- From: Steve Rowe [mailto:sar...@gmail.com] Sent: Thursday, January 17, 2013 1:26 AM To: dev@lucene.apache.org Subject: 4.1 release notes: please review I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
4.1 release notes: please review
I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release notes: please review
+1 Shai On Thu, Jan 17, 2013 at 9:26 AM, Steve Rowe sar...@gmail.com wrote: I took a crack at the Solr release note. I added CommonTermsQuery to the Lucene release note that Robert has been maintaining - looks good to me otherwise. Please help me whip these into shape. Solr: http://wiki.apache.org/solr/ReleaseNote41 Lucene: http://wiki.apache.org/lucene-java/ReleaseNote41 Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
I saw the branch_4x commit go by for this, but I believe it was AFTER the 4.1 branch was made. So, is it okay that 4.1 does not have this fix? But this is just a test change, anyway. -- Jack Krupansky -Original Message- From: Robert Muir Sent: Friday, January 11, 2013 7:52 AM To: dev@lucene.apache.org Subject: Re: 4.1 release I'd also like for Simon to have a chance to look at this bug: https://issues.apache.org/jira/browse/LUCENE-4676 I know he isnt back until next week... On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we
Re: 4.1 release
Thanks Jack, I committed Simon's patch on the 4.1 branch just now. - Steve On Jan 15, 2013, at 6:13 PM, Jack Krupansky j...@basetechnology.com wrote: I saw the branch_4x commit go by for this, but I believe it was AFTER the 4.1 branch was made. So, is it okay that 4.1 does not have this fix? But this is just a test change, anyway. -- Jack Krupansky -Original Message- From: Robert Muir Sent: Friday, January 11, 2013 7:52 AM To: dev@lucene.apache.org Subject: Re: 4.1 release I'd also like for Simon to have a chance to look at this bug: https://issues.apache.org/jira/browse/LUCENE-4676 I know he isnt back until next week... On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd
Re: 4.1 release
I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.comwrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.comwrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.comwrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
I'd also like for Simon to have a chance to look at this bug: https://issues.apache.org/jira/browse/LUCENE-4676 I know he isnt back until next week... On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark
Re: 4.1 release
On Fri, Jan 11, 2013 at 1:52 PM, Robert Muir rcm...@gmail.com wrote: I'd also like for Simon to have a chance to look at this bug: https://issues.apache.org/jira/browse/LUCENE-4676 I will take a look next week! simon I know he isnt back until next week... On Fri, Jan 11, 2013 at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out
Re: 4.1 release
On #lucene IRC, Robert Muir wrote i'm not RM this time I volunteer to be the 4.1 RM. Steve On Jan 11, 2013, at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark
Re: 4.1 release
+1 Sounds good. - Mark On Jan 11, 2013, at 12:53 PM, Steve Rowe sar...@gmail.com wrote: On #lucene IRC, Robert Muir wrote i'm not RM this time I volunteer to be the 4.1 RM. Steve On Jan 11, 2013, at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need
Re: 4.1 release
I thought you had already volunteered actually, but yes +1 On Fri, Jan 11, 2013 at 12:53 PM, Steve Rowe sar...@gmail.com wrote: On #lucene IRC, Robert Muir wrote i'm not RM this time I volunteer to be the 4.1 RM. Steve On Jan 11, 2013, at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do
Re: 4.1 release
We look forward to your success! -- Jack Krupansky -Original Message- From: Steve Rowe Sent: Friday, January 11, 2013 12:53 PM To: dev@lucene.apache.org Subject: Re: 4.1 release On #lucene IRC, Robert Muir wrote i'm not RM this time I volunteer to be the 4.1 RM. Steve On Jan 11, 2013, at 7:50 AM, Erick Erickson erickerick...@gmail.com wrote: P.S. Let's give dedicated souls the weekend to get stuff in for 4.1 if they want and cut the first RC early next week On Fri, Jan 11, 2013 at 7:48 AM, Erick Erickson erickerick...@gmail.com wrote: I'll take are of SOLR-4112 this morning, probably create another JIRA to track unit tests. There aren't any today and I have evidence from the field that it makes DIH usable so Erick On Thu, Jan 10, 2013 at 5:58 PM, Jack Krupansky j...@basetechnology.com wrote: The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2
Re: 4.1 release
As of now, there are two Blocker issues in JIRA with Fix Version 4.1: Dataimporting with SolrCloud Fails https://issues.apache.org/jira/browse/SOLR-4112 modify release process/scripts to use svn for rc/release publishing (svnpubsub) https://issues.apache.org/jira/browse/LUCENE-4134 (LUCENE-4431 - servlet-api.jar licensing - is listed as Blocker with Fix Version including 4.1, but this has been fixed in branch_4x, and was reopened only for 3.6.X backporting.) LUCENE-4547 https://issues.apache.org/jira/browse/LUCENE-4547 (DocValues 2.0) is listed as Blocker with Fix Version including 4.2, but recent commits to branches/lucene4547/ include changes to the Lucene41 codec. Looks like Fix Version should be changed to 4.1? I'd like to release soon. What else blocks this? Steve On Dec 31, 2012, at 2:08 PM, Mark Miller markrmil...@gmail.com wrote: I've started pushing on JIRA issue for a 4.1 release. If something is pushed that you are going to work on in the very near term, please put it back. I'll progressively get more aggressive about pushing and count on committers to fix any mistakes if they want something in 4.1. Remember, 4.2 can come shortly after 4.1. Next I will be pushing any 4.1 issues that have not been updated in a couple months. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
I set a couple of others to Blocker just now, which are related, probably dups. Shalin is assigned to them both. Solr 4 atomic update incorrect value when setting two or more values to a multivalue via XML update https://issues.apache.org/jira/browse/SOLR-4294 and Atomic Updates on multi-valued fields giving unexpected results https://issues.apache.org/jira/browse/SOLR-4286 Hopefully these aren't too bad and can make it in as well. Erik On Jan 10, 2013, at 14:12 , Steve Rowe wrote: As of now, there are two Blocker issues in JIRA with Fix Version 4.1: Dataimporting with SolrCloud Fails https://issues.apache.org/jira/browse/SOLR-4112 modify release process/scripts to use svn for rc/release publishing (svnpubsub) https://issues.apache.org/jira/browse/LUCENE-4134 (LUCENE-4431 - servlet-api.jar licensing - is listed as Blocker with Fix Version including 4.1, but this has been fixed in branch_4x, and was reopened only for 3.6.X backporting.) LUCENE-4547 https://issues.apache.org/jira/browse/LUCENE-4547 (DocValues 2.0) is listed as Blocker with Fix Version including 4.2, but recent commits to branches/lucene4547/ include changes to the Lucene41 codec. Looks like Fix Version should be changed to 4.1? I'd like to release soon. What else blocks this? Steve On Dec 31, 2012, at 2:08 PM, Mark Miller markrmil...@gmail.com wrote: I've started pushing on JIRA issue for a 4.1 release. If something is pushed that you are going to work on in the very near term, please put it back. I'll progressively get more aggressive about pushing and count on committers to fix any mistakes if they want something in 4.1. Remember, 4.2 can come shortly after 4.1. Next I will be pushing any 4.1 issues that have not been updated in a couple months. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
On Thu, Jan 10, 2013 at 11:12 AM, Steve Rowe sar...@gmail.com wrote: LUCENE-4547 https://issues.apache.org/jira/browse/LUCENE-4547 (DocValues 2.0) is listed as Blocker with Fix Version including 4.2, but recent commits to branches/lucene4547/ include changes to the Lucene41 codec. Looks like Fix Version should be changed to 4.1? This is a pretty bad bug (you cannot use docvalues with large segments: I initially made it blocker for that reason), but I think we are making good progress at a good pace. My personal opinion: Its fine to just move it out to 4.2, I'd rather have the time to get everything nice. A 4.1 would be an improvement on its own, even if there are known problems like that. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
-1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.1 release
The window of Monday through Wednesday sounds like a great target. Nothing says that the first RC has to be final. If whoever is doing the branch wants to do it on Monday rather than Tuesday, fine. If one or more of these nasty blockers gets fixed on Tuesday, we should still be open to a re-spin to put quality over a mere day or two of delay. But draw a hard line on Wednesday. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, January 10, 2013 3:36 PM To: dev@lucene.apache.org Subject: Re: 4.1 release Saying tomorrow without any date that gives anyone any time to do anything is out of nowhere to me. People in Europe and east of that will wake up and find out, oh today. While pressure has been building towards a release, no one has proposed a date for a cutoff. I think that is always only fair. I think that if you were desperate to cut off to blockers tomorrow, you should have called for that last week. Robert Muir's short term releases are not threatened by allowing people to plan and execute a release together. You can take that too far and do damage from the opposite direction. Giving people time to tie things up with a real deadline is only fair. We all know a nebulous deadline is not conducive to finishing up work. I think all releases should have a known date that we agree on that gives developers some time to finish what they are working on or what they believe is important for the release. At a minimum there should be a few days for this. A weekend involved only seems fair. This doesn't have to be a long time, but it should not require we file blockers and just seems like a friendly way to develop together. Monday is fine by me if others buy into it. Otherwise, we have taken 4 or 5 months for 4.1. Let's not drag it out another month. But let's not do the reverse and release it tonight. The sensible approach always seems like we should plan out some target dates on the list - dates that actually give devs a chance to respond to - and then follow through on those dates. - Mark On Jan 10, 2013, at 3:26 PM, Steve Rowe sar...@gmail.com wrote: Okay - I can see your logic, Mark, but this is not even close to out of nowhere. You yourself have been vocal about making a 4.1 release for a couple weeks now. I agree with Robert Muir that we should be promoting short turnaround releases. If it doesn't make this release, it'll make the next one, which will come out in a relatively short span of time. In this model, Blocker issues are the drivers, not Fix Version.If people want stuff in the release, they should mark their issue as Blocker. How about a compromise - next Monday we branch and only allow Blockers to block the release? Steve On Jan 10, 2013, at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: -1 from me - I don't like not giving people a target date to clean things up by. No one has given a proposed date to try and tie things up by - just calling 'hike is tomorrow' out of nowhere doesn't seem right to me. We have a lot of people working on this over a lot of timezones. I think we should do the right thing and give everyone at least a few days and a weekend to finish getting their issues into 4.1. - Mark On Jan 10, 2013, at 2:36 PM, Steve Rowe sar...@gmail.com wrote: I'd like to start sooner than next Tuesday. I propose to make the branch tomorrow, and only allow Blocker issues to hold up the release after that. A release candidate should then be possible by the middle of next week. Steve On Jan 10, 2013, at 2:27 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 10, 2013, at 2:12 PM, Steve Rowe sar...@gmail.com wrote: I'd like to release soon. What else blocks this? I think we should toss out a short term date (next tuesday?) for anyone to get in what they need for 4.1. Then just consider blockers after branching? Then release? Objections, better ideas? I think we should give a bit of time for people to finish up what's in flight or fix any blockers. Then we should heighten testing and allow for any new blockers, and then kick it out. If we need to do a 4.2 shortly after, so be it. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
4.1 release
I've started pushing on JIRA issue for a 4.1 release. If something is pushed that you are going to work on in the very near term, please put it back. I'll progressively get more aggressive about pushing and count on committers to fix any mistakes if they want something in 4.1. Remember, 4.2 can come shortly after 4.1. Next I will be pushing any 4.1 issues that have not been updated in a couple months. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
