> And this isn't just for our users. There are a lot of significant
> changes being proposed (or already committed) to the merging/indexing
> process, and I know I, for one, would benefit from having a good,
> coherent, unbroken writeup of it in the javadocs after the issues
> have been worked out.
Yes, definetly useful.
> By doing this at release time, we can avoid the dreaded pain of
> constantly rewriting it as it is being developed.
Should we try to decide which issues shall go into 2.2 by Tuesday
(06/05)? And then we could aim for a release about 2 weeks later, let's
say on Monday, 6/18? I will then create a branch on Tuesday or Wednesday
as Doug suggested and we will have a feature freeze on that branch until
2.2 is ready. During those two weeks we should test the build and
packaging, commit bug fixes if neccessary and focus on the javadocs,
as you suggest, Grant.
> As an aside, there are a few open issues already related to the
> index package and the demo/getting started page.
I think you refer to LUCENE-765 and LUCENE-805, right? Let's try to
do the javadoc improvements in some coordinated way: Let's gather here
which javadocs we want to improve for 2.2 by Tuesday as well and open
Jira issues. Well and then we have to assign those issues to volunteers
(why do I have the feeling that this is the hardest part :-) ).
> I am more concerned w/ the Javadocs at this point than the website,
> mostly b/c I think the website is a major undertaking (not that I am
> discouraging working on it), at least the part about writing a good
> tutorial and getting started page, but maybe I am wrong. I know that
> writing the scoring.html page was a significant undertaking for me and
> doing a similar page for indexing/analysis will likely be the same.
Yes, that's what I meant: writing these docs will take some time and
should not hold up the release.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
