You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2006/10/09 20:42:42 UTC
changes before release?
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.
-Yonik
Re: changes before release?
Posted by Yonik Seeley <yo...@apache.org>.
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?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 11/7/06, Chris Hostetter <ho...@fucit.org> 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?
Posted by Chris Hostetter <ho...@fucit.org>.
: > "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.
should we be specifying the liscences of all the jars we include in the
releases lib dir, even if they are ASF? ... of is that assumed?
(ignore my comment about supressing it -- i mnt in the binary builds, but
then i realized binary build is a misnomer -- we still need to include
everything that's in the source build, they just *also* contain the binary
build artifacts)
: > 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 was just getting confused about the whole "copyright notice" in every
file vs the "liscence header" in every file change ...
: I'd rather not put it in every single config file, but the docs
: suggest that anything significant needs it.
yeah ... better safe then sorry.
: > is our MANIFEST file "standards compliant" ??
:
: I'd accept a patch from someone that knows how to do this easily in ant...
I don't even know what it means for a MANIFEST to be standards compliant
... i've never relaly paid much attention to them.
-Hoss
Re: changes before release?
Posted by Yonik Seeley <yo...@apache.org>.
On 11/7/06, Chris Hostetter <ho...@fucit.org> 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?
Posted by Chris Hostetter <ho...@fucit.org>.
: 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.
Ohhhh.... we could make our lives easier and do a "Source Only Release"
-Hoss
Re: changes before release?
Posted by Yonik Seeley <yo...@apache.org>.
Making a Solr release fell off the radar for a little while, but I
think we should focus on making one soon. It now seems to be a
strongly suggested step toward graduation from the incubator.
Help is welcomed! Let us know if you see changes needed to satisfy
ASF release requirements & procedures.
http://incubator.apache.org/guides/releasemanagement.html
Browsing general@incubator for recent releases will also help
determine common requirements & pitfalls.
-Yonik
Re: changes before release?
Posted by Mike Klaas <mi...@gmail.com>.
On 10/9/06, Yoav Shapira <yo...@apache.org> wrote:
> On 10/9/06, Mike Klaas <mi...@gmail.com> 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?
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 10/9/06, Yonik Seeley <yo...@apache.org> 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 <mi...@gmail.com> 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?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/9/06, Yonik Seeley <yo...@apache.org> wrote:
> On 10/9/06, Bertrand Delacretaz <bd...@apache.org> 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?
Posted by Yonik Seeley <yo...@apache.org>.
On 10/9/06, Bertrand Delacretaz <bd...@apache.org> wrote:
> On 10/9/06, Yonik Seeley <yo...@apache.org> 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?
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Re: changes before release?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/9/06, Yonik Seeley <yo...@apache.org> 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?
Posted by Chris Hostetter <ho...@fucit.org>.
: - 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?
Posted by Mike Klaas <mi...@gmail.com>.
On 10/9/06, Yonik Seeley <yo...@apache.org> 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