incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #3
Date Mon, 23 May 2011 19:41:03 GMT
On Mon, May 23, 2011 at 10:56:11AM -0500, Peter Karman wrote:
> In file included from xs/XSBind.c:19:
> xs/XSBind.h:226:13: warning: missing terminating ' character
> xs/XSBind.h:232:13: warning: missing terminating ' character

That's the #error line in this block:
    #if (CHY_SIZEOF_CHAR == 1)
      #error Can't build unless sizeof(char) == 1

The message should probably be double-quoted.

> and then, fatally,
> t/001-build_indexes.t ................ Lucy object version 0.001000 does
> not match bootstrap parameter 0.001 at
> /usr/local/perl/589/lib/5.8.9/i686-linux/ line 249.
> which seems to be a bug with the XSLoader 0.10 in Perl 5.8.9 on my
> machine, for which 0.001000 != 0.001.
> The fix is to update our devel/bin/update_version script to catch the
> version string in lib/ I can do that for future, but not sure
> whether this constitutes a need to withdraw my +1 or not.
> Thoughts?

Nice catch, diagnosis, and fix.  :)

In my opinion, this is not a blocker -- though I'll go along if others

This is our first release.  Nobody has any CPAN dependency chains that are
going to break because Lucy starts failing.  And sloppy code can actually be
good for a project.  (There's some Apache aphorism to the tune of "bad code
plus good people equals successful project" that I'm unable to recall just
this moment.)

This is also certainly not our last portability bug -- but I don't think that
iterating during the current release voting cycle to fix such problems would
go well.  It costs too much to keep rerolling, tagging, voting, etc.

If we weren't inside Apache, we could do a dev release to CPAN and see what
the CPAN Testers smoke out.  But since that's not an option, I think we should
just plan to examine the reports for 0.1.0 and work aggressively to release 
0.1.1 with portability fixes in a couple of weeks.

For 0.2.0 and beyond, I think we should hold ourselves to a higher standard.
But the way to do that is to set up continuous integration, buildbots, smoke
testing, and so on, to get most portability work done well in advance of the
release voting cycle.  Once we're already verifying clean builds on a regular
basis, then blocking a release on a portability error makes more sense.

Being at Apache means that we have a lot of great infrastructure we can take
advantage of.  We're already using buildbot in two places: generating our RAT
report, and generating the new CMS website whenever we commit changes.  It's
also possible to use buildbot to build and run tests:

We should open an issue to look into getting that set up.

Marvin Humphrey

View raw message