lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
Date Tue, 09 May 2017 11:02:47 GMT
Sounds good, except can we not release beta001 to nuget? :)

--

Itamar Syn-Hershko
Freelance Developer & Consultant
Elasticsearch Partner
Microsoft MVP | Lucene.NET PMC
http://code972.com | @synhershko <https://twitter.com/synhershko>
http://BigDataBoutique.co.il/

On Tue, May 9, 2017 at 1:49 PM, Shad Storhaug <shad@shadstorhaug.com> wrote:

> Itamar,
>
> Thanks for your input. You make a compelling argument.
>
> Since the vote has passed and 4.8.0-beta00001 is already burnt (it exists
> in some people's NuGet cache and if we re-use it we can't be sure if they
> are testing the right copy), let's compromise and do both. Releasing now
> will do some damage control on the bootleg (which seriously needs to be
> made clear that it is not official and not production-ready) and ensures we
> reserve all of our NuGet package IDs. Starting a vote on 4.8.0-beta00002
> now will ensure the bug will be fixed within the same 72 hour timeframe.
>
> We should be able to determine by the nature of the bug reports if they
> are definitely not related to this and be able to fix those. Issues we are
> unsure about we can ask the users whether they still experience them after
> upgrading to 4.8.0-beta00002 and close if that patch fixes the issue(s).
>
> Peter has provided a workaround for the bug, which we can put into the
> release notes on NuGet.
>
> We can hold off any official announcement until after 4.8.0-beta00002 is
> released.
>
> Thoughts?
>
> Shad Storhaug (NightOwl888)
>
>
> -----Original Message-----
> From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On
> Behalf Of Itamar Syn-Hershko
> Sent: Tuesday, May 9, 2017 4:34 PM
> To: dev@lucenenet.apache.org
> Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
>
> This is quite a severe bug, and actually can cause index corruption. It
> can potentially also crash the application - some tests have been indeed
> failing with an exception being thrown due to access attempt of
> non-existing files. It is also probably going to fix quite a handful of
> those flakey tests (which will take a while to notice). If it wasn't that
> critical, I would have voted +1. In fact, I will probably cast an automatic
> +1 on the next vote.
>
> Tagging a version as official Beta, and having an announcement around it
> is bigger than just having the bits around (which we had as a while).
> Releasing a cleaner version will allow us to work on actual real bugs as
> they will be reported, instead of potentially responding to bug reports on
> something we know is already fixed even before we released. This is a
> better way of "collecting information" as you said.
>
> The compilation issues Simon has identified are important to fix (I had
> some myself) but do not constitute as critical IMO.
>
> We can start another vote now, and like I said 72 hours delay is not a big
> deal.
>
> --
>
> Itamar Syn-Hershko
> Freelance Developer & Consultant
> Elasticsearch Partner
> Microsoft MVP | Lucene.NET PMC
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> http://BigDataBoutique.co.il/
>
> On Tue, May 9, 2017 at 12:19 PM, Shad Storhaug <shad@shadstorhaug.com>
> wrote:
>
> > Stefan,
> >
> > > If you run into it, will it make your application crash or will it
> > destroy the index?
> >
> > It causes a crash under highly concurrent scenarios, and will most
> > likely affect all of the file-system directories. It does not affect
> > the index, otherwise some of the index tests would have detected it.
> > Peter van Ginkel (the user who discovered it) has been kind enough to
> > contribute a test that fails most of the time if the concurrency bug
> > exists, but before this none of our tests have been able to detect it.
> > Peter also has been able to work around this bug, and I have asked him
> to post the workaround at:
> > https://github.com/apache/lucenenet/pull/205
> >
> > It is a severe bug. Is it our most severe bug? Maybe. Is it severe
> > enough to destroy our reputation? Being that there is a bootleg copy
> > out there that is already doing just that (that is versioned as
> > production-ready and already has this bug), I would say we are better
> > off releasing with the bug than not. If we didn't have that issue to
> > contend with, I would agree with Itamar that we should re-roll the
> release.
> >
> > Thanks,
> > Shad Storhaug (NightOwl888)
> >
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: Tuesday, May 9, 2017 11:01 AM
> > To: dev@lucenenet.apache.org
> > Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
> >
> > On 2017-05-09, Shad Storhaug wrote:
> >
> > > So technically the vote passes. However, I will give it some more
> > > time
> > in case anyone else wants to weigh in on whether the issues we have
> > are significant enough to reset the release. Presscott, Stefan, Simon,
> WDYT?
> >
> > As you may know I'm not a user of Lucene.Net myself, so take my
> > opinion with a grain of salt.
> >
> > I'm not sure about the impact of the bug. If you run into it, will it
> > make your application crash or wil it destroy the index? In the later
> > case I'd say we should re-roll the release. Otherwise we should
> > publish the release, fix the bug and plan for a second beta soon.
> >
> > Stefan
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message