Re: changes before release?
On 11/7/06, Chris Hostetter [EMAIL PROTECTED] wrote: ant nightly currenlty includes servlet-api-2.4.jar in the lib dir .. but we don't have any license for it .. we should probably just be supressing it from the release correct? (it's only for compilation as i recall) I grabbed this jar from Tomcat, and looking at the source, it's ASF licensed. do we have the apache licenese in a comment in every file? .. the release doc suggests we should, but i also seem to remember someone saying that policy had changed recently. docs seem to say so... but most other projects don't seem to follow this. I'd rather not put it in every single config file, but the docs suggest that anything significant needs it. the META-INF of our jars/wars doesn't inlcude LICENSE and NOTICE files is our MANIFEST file standards compliant ?? I'd accept a patch from someone that knows how to do this easily in ant... it looks like we should generate seperate .tar.gz/.zip binary and source releases, and use Ant's fixcrlf to make all text files in the .zip releases contain windows formated files. Exclude shell scripts... I just upgraded cygwin, and the newest bash sees line endings with \r\n as having a literal \r -Yonik
Re: changes before release?
Unless there are objections, I'll start of by switching to the new license header and then try and search for any files that may be missing it. -Yonik
Re: changes before release?
: Help is welcomed! Let us know if you see changes needed to satisfy : ASF release requirements procedures. : http://incubator.apache.org/guides/releasemanagement.html (i'm kinda tired so this may ramble...) ant nightly currenlty includes servlet-api-2.4.jar in the lib dir .. but we don't have any license for it .. we should probably just be supressing it from the release correct? (it's only for compilation as i recall) the incubator release docs mention having both LICENSE files and NOTICE files for libraries ... not sure what the difference is, but we only have a LICENSE file for xpp -- no NOTICE. do we have the apache licenese in a comment in every file? .. the release doc suggests we should, but i also seem to remember someone saying that policy had changed recently. we don't have a STATUS doc .. not sure what's suppose to go in that. the META-INF of our jars/wars doesn't inlcude LICENSE and NOTICE files is our MANIFEST file standards compliant ?? our solr-1.0-src.zip seems to unzip everything into the current working directory ... it's also just the src/ dir without any LICENSE, CHANGES, README or build.xml it looks like we should generate seperate .tar.gz/.zip binary and source releases, and use Ant's fixcrlf to make all text files in the .zip releases contain windows formated files. O we could make our lives easier and do a Source Only Release -Hoss
Re: changes before release?
On 11/7/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...the incubator release docs mention having both LICENSE files and NOTICE files for libraries ... not sure what the difference is, but we only have a LICENSE file for xpp -- no NOTICE... AFAIK there is one global NOTICE file for the project, see [1]. ...do we have the apache licenese in a comment in every file? .. the release doc suggests we should, but i also seem to remember someone saying that policy had changed recently... Also from [1]: files without any degree of creativity do not need the license header. ARAT is useful in checking for license headers, see http://code.google.com/p/arat/ ... we could make our lives easier and do a Source Only Release... (not sure if you're being ironic here;-) I don't think a source only release is appropriate for Solr. It's fine for tools aimed at software developers, but many Solr users will just want to use it out of the box. -Bertrand [1] http://www.apache.org/legal/src-headers.html
Re: changes before release?
On 10/9/06, Yoav Shapira [EMAIL PROTECTED] wrote: On 10/9/06, Mike Klaas [EMAIL PROTECTED] wrote: The most important things that come to mind: - stabilize/review external api (query parameters, schema.xml/solrconfig.xml format, XML response format). (for instance, should debugQuery/explainOther combo be changed to debug/debug.otherQuery? Is the other query explain functionality important?) Yes, important, but not essential. Whatever release we do first is likely to be an alpha release to show a healthy and active community and focus on non-technical issues towards graduating from the incubator. I actually think that it is relatively important for the long-term future of the project. While we may cut an alpha release with no guarantees about api stability, having a stable api will significantly improve future impression of the product as well as reduce future compatibility issues. Having a smaller number of future api changes gives credence to the product's maturity and suitability for use. We surely can take time to do both this and the apache requirements. regards, -Mike
Re: changes before release?
On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...At the technical level, what do people thing should be changed/committed before we do?... Not sure what you mean by technical level...if I'm allowed to suggest my own patch, I think http://issues.apache.org/jira/browse/SOLR-49 (XSLTResponseWriter) could be committed. It has no impact on existing code and can be useful for simple setups, demos, etc. -Bertrand
Re: changes before release?
On 10/9/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...At the technical level, what do people thing should be changed/committed before we do?... Not sure what you mean by technical level There is other stuff that needs to be done before we can release, such as a change of copyright notices to comply with new ASF requirements. I imagine incubator-general will go over the first release we make with a fine-tooth comb looking for compliance with ASF release rules. ...if I'm allowed to suggest my own patch, I think http://issues.apache.org/jira/browse/SOLR-49 (XSLTResponseWriter) could be committed. It has no impact on existing code and can be useful for simple setups, demos, etc. Definitely... I'll take another look at the latest version. Oh, and thanks for all the work you've been doing getting the word out on Solr! http://wiki.apache.org/cocoon/GT2006Notes Perhaps we could link your presentation here? http://wiki.apache.org/solr/SolrResources -Yonik
Re: changes before release?
On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 10/9/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: ...Not sure what you mean by technical level There is other stuff that needs to be done before we can release, such as a change of copyright notices to comply with new ASF requirements Ok, got it now. ...Perhaps we could link your presentation here? http://wiki.apache.org/solr/SolrResources Good idea, done! My presentation was well received at the Cocoon GetTogether, and I talked with several people who are considering Solr for their projects. The question that usually comes is: how to convince my manager to use software that is still in incubation, so making a release is certainly a Good Thing. -Bertrand
Re: changes before release?
On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: I think we should plan on making a release soon (end of October?) At the technical level, what do people thing should be changed/committed before we do? Off the top of my head, perhaps http://issues.apache.org/jira/browse/SOLR-2 because it has to do with interface, and none of the java clients are really locked down yet. The most important things that come to mind: - stabilize/review external api (query parameters, schema.xml/solrconfig.xml format, XML response format). (for instance, should debugQuery/explainOther combo be changed to debug/debug.otherQuery? Is the other query explain functionality important?) - review/trim internal api. Not as crucial as the above, but still important. An example is that fields have two write() methods, one for the old XMLWriter and another for a generic TextResponseWriter. Perhaps we could make a parent interface for output writing so that this can be reduced to one method (the methods are identical for most of defined fields). - remove all deprecated/compatibility code. -Mike
Re: changes before release?
Hi, On 10/9/06, Yonik Seeley [EMAIL PROTECTED] wrote: There is other stuff that needs to be done before we can release, such as a change of copyright notices to comply with new ASF requirements. I imagine incubator-general will go over the first release we make with a fine-tooth comb looking for compliance with ASF release rules. Yes. Speaking with my incubator PMC hat on, I think we should do the release prep stuff (LICENSE and NOTICE files, license resolution, etc.) first before the technical things, because we know less about them, they're required, and we are likely to underestimate the effort. On 10/9/06, Mike Klaas [EMAIL PROTECTED] wrote: The most important things that come to mind: - stabilize/review external api (query parameters, schema.xml/solrconfig.xml format, XML response format). (for instance, should debugQuery/explainOther combo be changed to debug/debug.otherQuery? Is the other query explain functionality important?) Yes, important, but not essential. Whatever release we do first is likely to be an alpha release to show a healthy and active community and focus on non-technical issues towards graduating from the incubator. - review/trim internal api. Not as crucial as the above, but still important. An example is that fields have two write() methods, one for the old XMLWriter and another for a generic TextResponseWriter. Perhaps we could make a parent interface for output writing so that this can be reduced to one method (the methods are identical for most of defined fields). Plenty of those examples around, all worthy of review and trimming, but see above. - remove all deprecated/compatibility code. Yes, and this one actually has a bonus in that we don't have to worry about licensing / noting (in our release documentation) any source we don't ship... Yoav
Re: changes before release?
: - stabilize/review external api (query parameters, : schema.xml/solrconfig.xml format, XML response format). (for Right ... it's not something that i've thought about lately, but doing something with the XSD in SOLR-17 so that the XML output format can be validated would probably be a good idea for an official release. -Hoss
Re: changes before release?
: http://issues.apache.org/jira/browse/SOLR-49 (XSLTResponseWriter) : could be committed. It has no impact on existing code and can be : useful for simple setups, demos, etc. On the subject of stablizing the external APIs, the one thing about your patch in it's current format that I rememebr not being fond of using XML node attributes to configure queryResponseWriters instead of refactoring the code used to get requestHandler configuration using nested XML as a NamedList (which can easily be converted to SolrParams). Other then that, i agree it would be a really handy thing to have in our first release. -Hoss