You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Logan Bell <lo...@apache.org> on 2012/05/10 18:01:19 UTC

[ANNOUNCE] Apache Lucy 0.3.1 released

Greetings,

The Apache Lucy team is pleased to announce the release of version 0.3.1!

The Apache Lucy search engine library provides full-text search for dynamic
programming languages.  For a list of issues resolved in this version,
please
see the release notes:

  http://www.apache.org/dist/lucy/CHANGES-0.3.1.txt

The most recent release can be obtained from our download page:

  http://lucy.apache.org/download.html

For general information on Apache Lucy, please visit the project website:

  http://lucy.apache.org/

Regards,

Logan Bell, on behalf of the Apache Lucy development team and community

Re: [lucy-user] [ANNOUNCE] Apache Lucy 0.3.1 released

Posted by Peter Karman <pe...@peknet.com>.
Grant McLean wrote on 5/10/12 4:25 PM:

> 
> I *think* the attached pacth is all that's required to fix this.

Thanks, Grant. Committed to trunk as r1336991 and branches/0.3 as r1336992.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-dev] Fwd: [lucy-user] META resources patch

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jul 13, 2012 at 9:39 AM, Logan Bell <lo...@gmail.com> wrote:
> I agree it's a small fix, but we must ask the obvious question what
> justifies a bug release? Looking through our wiki I don't see any sort of
> guidelines for this.

You need a Release Manager willing to do the work and a majority vote with a
quorum of 3 PMC members voting +1.

Power resides in the do-ocracy.  It's up to the judgment of those individuals.

Personally, I think a bugfix release would be justified if we try to make some
progress on this class of problem in Charmonizer:

  http://cpantesters.org/cpan/report/ffcaade6-6cc9-1014-8d81-4edd8ede4cb4

We have had similar problems with earlier releases:

  http://www.cpantesters.org/cpan/report/69b25746-6cfa-1014-850b-e0170163837e
  http://www.cpantesters.org/cpan/report/db586700-63e1-11e1-b759-ec922b0aa2c1
  http://www.cpantesters.org/cpan/report/14256dac-6893-11e1-ba5b-ffa051838b10

I think they are all due to failed file system operations, maybe unchecked
remove() calls that are failing on busy Windows systems.  It would be nice to
go over our code and make sure we are printing useful error messages to stderr
whenever system calls fail.  Then at least we would have a better shot at
figuring out what's going wrong from CPAN tester failure output, since I can't
seem to duplicate these failures locally.

> My instincts tell me that since we're a small project that quick bug
> releases to satisfy users of the project is the best way to grow the
> project's user/dev base.

Kudos for keeping community growth in mind.  Our 0.3.2 release was needed
because LUCY-238 had no workaround.

Marvin Humphrey

Re: [lucy-dev] Fwd: [lucy-user] META resources patch

Posted by Peter Karman <pe...@peknet.com>.
On 7/13/12 11:39 AM, Logan Bell wrote:
> I agree it's a small fix, but we must ask the obvious question what
> justifies a bug release? Looking through our wiki I don't see any sort
> of guidelines for this. My instincts tell me that since we're a small
> project that quick bug releases to satisfy users of the project is the
> best way to grow the project's user/dev base. Or do we wait until we
> have N number of bug fixes? In my mind, a bug fix releases should be
> fast and prudent, and maybe each bug fix release should be decided upon
> as needed.
>
> I'll be happy to outline a wiki page describing what justifies a bug fix
> pending the outcome of this chain.

documenting some guidelines would be a Good Thing.

I guess I'm going off my own instincts based on my CPAN contributions. 
Unless a commit represents a fix to a failing test or a bug someone has 
reported, I don't bother releasing a new version until I've accumulated 
what feels like a critical mass of change. It's a fairly arbitrary 
decision-making process, I admit, and propelled mostly by feeling rather 
than rational guidelines. Here are some of the questions I find myself 
posing to myself:

  * without this release, will people fail to use the code?
  * how long has it been since the last release?
  * will releasing this code gain me users?
  * will releasing this code lose me users?
  * will my mental cache, where I carry around a seemingly infinite set 
of TODOs, feel better being flushed of responsibility for this set of 
changes?

Releasing my personal code to CPAN is easy: I just decide, and can push 
out a release in a minute or two.

Releasing the Apache Way requires a VOTE thread, which requires building 
of artifacts, testing those, several svn commits, etc.

So my burden of proof, my release threshold, feels significantly higher 
for Lucy than it does for my CPAN code. That's because I'm lazy. I find 
solace in the fact that laziness is sometimes a virtue.

I have no philosophical objection to releasing a 0.3.3 to fix this CPAN 
metadata issue, as long as I don't have to do any work myself. That's my 
laziness talking. OTOH, I did make the effort to take Grant's patch and 
commit it, within a few hours of seeing it on the list, so my laziness 
is selective.

/end-of-brain-log


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-dev] Fwd: [lucy-user] META resources patch

Posted by Logan Bell <lo...@gmail.com>.
I agree it's a small fix, but we must ask the obvious question what
justifies a bug release? Looking through our wiki I don't see any sort of
guidelines for this. My instincts tell me that since we're a small project
that quick bug releases to satisfy users of the project is the best way to
grow the project's user/dev base. Or do we wait until we have N number of
bug fixes? In my mind, a bug fix releases should be fast and prudent, and
maybe each bug fix release should be decided upon as needed.

I'll be happy to outline a wiki page describing what justifies a bug fix
pending the outcome of this chain.

Thanks,
Logan

On Fri, Jul 13, 2012 at 9:10 AM, Peter Karman <pe...@peknet.com> wrote:

> On 7/13/12 11:06 AM, Logan Bell wrote:
>
>> Should this be merged down to bug branch and should and in that regard
>> should we do another release? It seems like we should do our best to get a
>> bug fix out to him since he's taken the time submit these patches.
>>
>>
> yes, could merge down to 0.3.x branch. but it seems fairly minor thing to
> do a release for all by itself.
>
>
>
> --
> Peter Karman  .  http://peknet.com/  .  peter@peknet.com
>

Re: [lucy-dev] Fwd: [lucy-user] META resources patch

Posted by Peter Karman <pe...@peknet.com>.
On 7/13/12 11:06 AM, Logan Bell wrote:
> Should this be merged down to bug branch and should and in that regard
> should we do another release? It seems like we should do our best to get a
> bug fix out to him since he's taken the time submit these patches.
>

yes, could merge down to 0.3.x branch. but it seems fairly minor thing 
to do a release for all by itself.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

[lucy-dev] Fwd: [lucy-user] META resources patch

Posted by Logan Bell <lo...@apache.org>.
Should this be merged down to bug branch and should and in that regard
should we do another release? It seems like we should do our best to get a
bug fix out to him since he's taken the time submit these patches.

Thoughts?

Thanks,
Logan

---------- Forwarded message ----------
From: Peter Karman <pe...@peknet.com>
Date: Wed, Jul 11, 2012 at 6:59 PM
Subject: Re: [lucy-user] META resources patch
To: user@lucy.apache.org


Grant McLean wrote on 7/11/12 6:42 PM:

>
> It turns out that my patch was not achieving the desired aim because the
> 'meta_add' values from Build.PL were being overwritten by the no_index
> code in Build::Lucy.  The attached patch should fix that.

thanks, Grant. Applied to trunk as r1360509.


--
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-user] META resources patch

Posted by Peter Karman <pe...@peknet.com>.
Grant McLean wrote on 7/11/12 6:42 PM:

> 
> It turns out that my patch was not achieving the desired aim because the
> 'meta_add' values from Build.PL were being overwritten by the no_index
> code in Build::Lucy.  The attached patch should fix that.

thanks, Grant. Applied to trunk as r1360509.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

[lucy-user] META resources patch

Posted by Grant McLean <gr...@catalyst.net.nz>.
On Fri, 2012-05-11 at 09:25 +1200, Grant McLean wrote:
> On Thu, 2012-05-10 at 09:01 -0700, Logan Bell wrote:
> > The Apache Lucy team is pleased to announce the release of version 0.3.1!
> 
> Thanks to all the project team for your ongoing efforts.
> 
> One small thing for a future release ...
> 
> The metadata for the CPAN package does not list details of a bugtracker.
> The result is that the "Bugs" link on the CPAN search sites link to the
> default RT bug queue:
> 
>   https://metacpan.org/release/Lucy
>   http://search.cpan.org/dist/Lucy/
> 
> It looks like there are even a couple of issues logged there.  Whereas I
> assume issues should really be tracked at:
> 
>   https://issues.apache.org/jira/browse/LUCY
> 
> I *think* the attached pacth is all that's required to fix this.

It turns out that my patch was not achieving the desired aim because the
'meta_add' values from Build.PL were being overwritten by the no_index
code in Build::Lucy.  The attached patch should fix that.

Regards
Grant



Re: [lucy-user] [ANNOUNCE] Apache Lucy 0.3.1 released

Posted by Grant McLean <gr...@catalyst.net.nz>.
On Thu, 2012-05-10 at 09:01 -0700, Logan Bell wrote:
> The Apache Lucy team is pleased to announce the release of version 0.3.1!

Thanks to all the project team for your ongoing efforts.

One small thing for a future release ...

The metadata for the CPAN package does not list details of a bugtracker.
The result is that the "Bugs" link on the CPAN search sites link to the
default RT bug queue:

  https://metacpan.org/release/Lucy
  http://search.cpan.org/dist/Lucy/

It looks like there are even a couple of issues logged there.  Whereas I
assume issues should really be tracked at:

  https://issues.apache.org/jira/browse/LUCY

I *think* the attached pacth is all that's required to fix this.

Cheers
Grant