You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2011/11/22 04:06:31 UTC
[lucy-dev] 0.3.0
What stands in our way for a 0.3.0 release?
We've had a lot of churn in trunk over the last couple of months, particularly
exorcising Parse::RecDescent and adding utf8proc. I think we should aim for a
new release as soon as whatever top-priority TODOs are identified and addressed.
On my list:
* the highlighter bug (LUCY-182)
* any 0.2.2 cpantesters failures
Thoughts?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Re: 0.3.0
Posted by Peter Karman <pe...@peknet.com>.
On 12/21/11 8:36 AM, Peter Karman wrote:
>
> Marvin finished LUCY-142 last night, so as of this morning all
> 0.3.0-related tickets are resolved.
>
> Since this is such a significant release (i.e. lots of svn churn) I'd
> like to propose that we approach the release in the following way:
>
> * create a 0.3.0 branch from trunk
>
> * build and release a 0.2.9_01 version to CPAN so we can get some
> cpantesters feedback in advance of an official 0.3.0 release
>
> * pending cpantesters feedback, create a 0.3.0 RC1 for an official VOTE
> thread on this list
>
> If I don't hear objections to this approach, I'll claim lazy concensus
> and start executing after Dec 25.
>
/me claims lazy concensus.
I will cut the 0.3 branch from trunk tonight. If you have any pending
commits to trunk, please make them or let me know that I would hold off
on the branch.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Re: 0.3.0
Posted by Peter Karman <pe...@peknet.com>.
On 12/15/11 8:45 PM, Peter Karman wrote:
> I will check in on the status of 0.3.0 tickets this time next week and see where
> we're at.
Marvin finished LUCY-142 last night, so as of this morning all
0.3.0-related tickets are resolved.
Since this is such a significant release (i.e. lots of svn churn) I'd
like to propose that we approach the release in the following way:
* create a 0.3.0 branch from trunk
* build and release a 0.2.9_01 version to CPAN so we can get some
cpantesters feedback in advance of an official 0.3.0 release
* pending cpantesters feedback, create a 0.3.0 RC1 for an official
VOTE thread on this list
If I don't hear objections to this approach, I'll claim lazy concensus
and start executing after Dec 25.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Re: 0.3.0
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 12/12/11 6:06 PM:
> JIRA has an option to "archive" an unreleased version; I used it previously
> for 0.1.1. We should do the same for 0.2.3. Directions for navigating JIRA
> are tedious to write out, so catch me on #lucy_dev.
done. thanks.
I will check in on the status of 0.3.0 tickets this time next week and see where
we're at.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Re: 0.3.0
Posted by Nick Wellnhofer <we...@aevum.de>.
On 13/12/11 01:06, Marvin Humphrey wrote:
> Nick, can you please try assigning those two issues to yourself and then
> resolve them? I just updated our JIRA "roles", so if there's anything you
> weren't able to do before, you ought to be able to do it now.
Yes, now I'm allowed assign issues to myself and resolve them. I did so
for LUCY-182, LUCY-191, and LUCY-196.
Nick
Re: [lucy-dev] Re: 0.3.0
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Dec 11, 2011 at 08:37:30PM -0600, Peter Karman wrote:
> Peter Karman wrote on 11/21/11 9:06 PM:
> > What stands in our way for a 0.3.0 release?
>
> AFAICS, these are the outstanding issues blocking a 0.3.0 release:
>
> https://issues.apache.org/jira/browse/LUCY/fixforversion/12317044
(FWIW, you actually need to click on the "eye" icon to get a complete list of
unresolved issues. That link shows 3 -- there were 6 in total.)
Fixes for the following issues had already been committed, so I resolved them:
https://issues.apache.org/jira/browse/LUCY-185
Improve error handling when required params not supplied
https://issues.apache.org/jira/browse/LUCY-186
Terminate connection from SearchClient properly
https://issues.apache.org/jira/browse/LUCY-188
Highlighter should accept weighted Queries (Compilers)
This issue is still outstanding:
https://issues.apache.org/jira/browse/LUCY-187
Adapt to GC changes in Perl 5.15
Nick committed fixes for the following issues:
https://issues.apache.org/jira/browse/LUCY-182
highlighter bug when searching for duplicate terms [wordX wordX]
https://issues.apache.org/jira/browse/LUCY-191
Unicode normalization
Nick, can you please try assigning those two issues to yourself and then
resolve them? I just updated our JIRA "roles", so if there's anything you
weren't able to do before, you ought to be able to do it now.
> Are there any other issues you are aware of?
I added this one:
https://issues.apache.org/jira/browse/LUCY-197
Clean whitespace for 0.3.0
Then there's this:
https://issues.apache.org/jira/browse/LUCY-197
UAX #29 Tokenizer
Nick should set that issue to a "fix version" of 0.3.0 and resolve it. That
way it will show up in the CHANGES entry for 0.3.0.
> I've taken the liberty of zapping the 0.2.3 release tickets in Jira since that
> release appears superseded in favor of a 0.3.0. If there are objections, please
> raise them here; I'll consider 0.2.3 a non-starter via lazy concensus if I've
> heard nothing otherwise in 72 hours.
JIRA has an option to "archive" an unreleased version; I used it previously
for 0.1.1. We should do the same for 0.2.3. Directions for navigating JIRA
are tedious to write out, so catch me on #lucy_dev.
> Consider this email me volunteering to catherd the 0.3.0 release toward the
> finish line.
Yay!
Marvin Humphrey
[lucy-dev] Re: 0.3.0
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 11/21/11 9:06 PM:
> What stands in our way for a 0.3.0 release?
AFAICS, these are the outstanding issues blocking a 0.3.0 release:
https://issues.apache.org/jira/browse/LUCY/fixforversion/12317044
Are there any other issues you are aware of?
I've taken the liberty of zapping the 0.2.3 release tickets in Jira since that
release appears superseded in favor of a 0.3.0. If there are objections, please
raise them here; I'll consider 0.2.3 a non-starter via lazy concensus if I've
heard nothing otherwise in 72 hours.
Consider this email me volunteering to catherd the 0.3.0 release toward the
finish line.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Nov 21, 2011 at 09:06:31PM -0600, Peter Karman wrote:
> What stands in our way for a 0.3.0 release?
>
> We've had a lot of churn in trunk over the last couple of months, particularly
> exorcising Parse::RecDescent and adding utf8proc.
Another important change not in the 0.2.x line is the swapout of JSON::XS and a
translation layer for a core JSON parser.
> I think we should aim for a new release as soon as whatever top-priority
> TODOs are identified and addressed.
In addition to your list, I would cringe if ClusterSearcher were to go out in
its present state. If we want to triage it, perhaps we can disable the select
loop and just go with serial collection of responses -- the remotes still work
in parallel that way. It will still be fragile and inflexible, but hopefully
that will stop it from crashing outright.
Also, we should run lucytidy.pl after adding some new excludes:
diff --git a/devel/bin/lucytidy.pl b/devel/bin/lucytidy.pl
index ddb61cc..778b1e7 100755
--- a/devel/bin/lucytidy.pl
+++ b/devel/bin/lucytidy.pl
@@ -26,7 +26,12 @@ use Fcntl;
my $ignore = qr/(
\.svn
| \.git
+ | clownfish.src.CFCLexHeader
+ | devel.bin.release_commands.pl
| modules.analysis.snowstem.source
+ | modules.unicode.utf8proc
+ | lemon.lemon.c
+ | lemon.lempar.c
| perl.sample
)/x;
> On my list:
>
> * the highlighter bug (LUCY-182)
We have a patch now from Nick Wellnhofer which hopefully exterminates this
persistent little critter.
> * any 0.2.2 cpantesters failures
These fall into three categories.
First, there's the Perl 5.15.x destruction bug. I have a provisional patch
which seems to work. However, I don't fully understand why it works, which
makes me nervous.
Second, there's one Strawberry Perl failure arising from this Charmonizer probe
error:
64-bit types, but no literal syntax found
It's GCC, so we should assume that LL and ULL are OK as suffixes for 64-bit
integer literals and that the problem therefore resides in our probe logic or
probing mechanism. Who knows why that probe seems to work absolutely
everywhere else, including my copy of Strawberry Perl, though. Sigh. I'd just
let that one go for now.
Last, we have a slew of failures on OpenBSD because of pthreads. I took a
blind stab at this one, but looks like I missed:
https://issues.apache.org/jira/browse/LUCY-157
We should be able to solve that problem if we can get access to an OpenBSD box.
Marvin Humphrey