You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Prescott Nasser <ge...@hotmail.com> on 2011/04/04 08:59:07 UTC
[Lucene.Net] release 2.9.4
Hey all,
I know we have a number of outstanding JIRA issues, but I think most of them have been handled for the 2.9.4 release? Do we have anything outstanding that is holding back a new release?
~P
Re: [Lucene.Net] release 2.9.4
Posted by digy digy <di...@gmail.com>.
Thanks, updated.
DIGY
On Tue, Apr 5, 2011 at 11:34 PM, Granroth, Neal V. <
neal.granroth@thermofisher.com> wrote:
>
> I had no difficulty building it in Visual Studio 2005.
> The assembly copyright information appears to be out of date; shouldn't it
> read 2011 not 2009 ?
>
>
> - Neal
>
> -----Original Message-----
> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
> Sent: Tuesday, April 05, 2011 2:23 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: Troy Howard
> Subject: Re: [Lucene.Net] release 2.9.4
>
> Tag [+1]
>
> svn export and command line build successful; I'll keep you all posted . .
> .
>
> On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
> > Yes. Once we're ready to call this revision an RC, it should be tagged as
> such.
> >
> > Wyatt: Thanks for helping to test! Looking forward to your results.
> >
> > Thanks,
> > Troy
> >
> >
> > On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
> > <ne...@thermofisher.com> wrote:
> >>
> >> No, the URL in DIGY's email apepars correct and the SVN revision appears
> to be 1086410.
> >>
> >> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for
> previous release candidates?
> >>
> >> - Neal
> >>
> >> -----Original Message-----
> >> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
> >> Sent: Tuesday, April 05, 2011 12:15 PM
> >> To: lucene-net-dev@lucene.apache.org
> >> Cc: digy digy
> >> Subject: Re: [Lucene.Net] release 2.9.4
> >>
> >> Thanks. For anyone watching, the corrected clickable link is
> >> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
> >>
> >> Also, just to make sure we are looking at this right, the revision we
> >> should be using is 1089138 -- main thing is I've been in and out of
> >> town, not caught up on anything and I'd hate to start building stuff
> >> against the wrong version . .
> >>
> >> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
> >>> Sorry, no binaries. You can download the source from
> >>>
> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
> >>>
> >>> DIGY
> >>>
> >>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <
> wyatt.barnett@gmail.com>wrote:
> >>>
> >>>> Actually about to dive into a big search tweaking spike in a certain
> >>>> project here, happy to do it on 2.9.4. Got binaries?
> >>>>
> >>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com>
> wrote:
> >>>> > We don't have any sort of QA report on the latest build. DIGY called
> >>>> > for testing, but I haven't seen anyone respond to that request
> >>>> > indicating successful testing.
> >>>> >
> >>>> > So, how do we want to manage this?
> >>>> >
> >>>> > In the business world, we'd never think of making a release without
> >>>> > extensive QA first. In my other open source projects, either we've
> >>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
> >>>> > release, or just crossed our fingers because the user base was too
> >>>> > small.
> >>>> >
> >>>> > Lucene.Net is a fairly high-profile project, with a large user base.
> I
> >>>> > think it would not be responsible to make a release without a formal
> >>>> > QA process. We do have extensive unit tests, but do you think those
> >>>> > are sufficient to cover our QA needs? Should we try to find
> community
> >>>> > members with a specialty in software testing that would be willing
> to
> >>>> > fulfill this role on our project? Should we just swap hats?
> >>>> >
> >>>> > I didn't worry about this issue with the latest 2.9.2 release
> because
> >>>> > it was QAed by the user base for a long time before it was an
> >>>> > 'official release'. Maybe this is an effective tactic? Release
> first,
> >>>> > and let the user base roll in bug reports fixing them on yet later
> >>>> > minor maintenance releases? This seems to be the method a lot of
> >>>> > projects use (i.e. no specific QA process, but rather an organic
> >>>> > process of 'try our best then deal with bug reports later').
> >>>> >
> >>>> > What do we think about this?
> >>>> >
> >>>> > Thanks,
> >>>> > Troy
> >>>> >
> >>>> >
> >>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <
> geobmx540@hotmail.com>
> >>>> wrote:
> >>>> >>
> >>>> >> Hey all,
> >>>> >>
> >>>> >> I know we have a number of outstanding JIRA issues, but I think
> most of
> >>>> them have been handled for the 2.9.4 release? Do we have anything
> >>>> outstanding that is holding back a new release?
> >>>> >>
> >>>> >> ~P
> >>>> >
> >>>>
> >>>
> >>
> >
>
RE: [Lucene.Net] release 2.9.4
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
I had no difficulty building it in Visual Studio 2005.
The assembly copyright information appears to be out of date; shouldn't it read 2011 not 2009 ?
- Neal
-----Original Message-----
From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
Sent: Tuesday, April 05, 2011 2:23 PM
To: lucene-net-dev@lucene.apache.org
Cc: Troy Howard
Subject: Re: [Lucene.Net] release 2.9.4
Tag [+1]
svn export and command line build successful; I'll keep you all posted . . .
On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
> Yes. Once we're ready to call this revision an RC, it should be tagged as such.
>
> Wyatt: Thanks for helping to test! Looking forward to your results.
>
> Thanks,
> Troy
>
>
> On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
> <ne...@thermofisher.com> wrote:
>>
>> No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
>>
>> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates?
>>
>> - Neal
>>
>> -----Original Message-----
>> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
>> Sent: Tuesday, April 05, 2011 12:15 PM
>> To: lucene-net-dev@lucene.apache.org
>> Cc: digy digy
>> Subject: Re: [Lucene.Net] release 2.9.4
>>
>> Thanks. For anyone watching, the corrected clickable link is
>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
>>
>> Also, just to make sure we are looking at this right, the revision we
>> should be using is 1089138 -- main thing is I've been in and out of
>> town, not caught up on anything and I'd hate to start building stuff
>> against the wrong version . .
>>
>> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
>>> Sorry, no binaries. You can download the source from
>>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>>>
>>> DIGY
>>>
>>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>>>
>>>> Actually about to dive into a big search tweaking spike in a certain
>>>> project here, happy to do it on 2.9.4. Got binaries?
>>>>
>>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>>>> > We don't have any sort of QA report on the latest build. DIGY called
>>>> > for testing, but I haven't seen anyone respond to that request
>>>> > indicating successful testing.
>>>> >
>>>> > So, how do we want to manage this?
>>>> >
>>>> > In the business world, we'd never think of making a release without
>>>> > extensive QA first. In my other open source projects, either we've
>>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>>>> > release, or just crossed our fingers because the user base was too
>>>> > small.
>>>> >
>>>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>>>> > think it would not be responsible to make a release without a formal
>>>> > QA process. We do have extensive unit tests, but do you think those
>>>> > are sufficient to cover our QA needs? Should we try to find community
>>>> > members with a specialty in software testing that would be willing to
>>>> > fulfill this role on our project? Should we just swap hats?
>>>> >
>>>> > I didn't worry about this issue with the latest 2.9.2 release because
>>>> > it was QAed by the user base for a long time before it was an
>>>> > 'official release'. Maybe this is an effective tactic? Release first,
>>>> > and let the user base roll in bug reports fixing them on yet later
>>>> > minor maintenance releases? This seems to be the method a lot of
>>>> > projects use (i.e. no specific QA process, but rather an organic
>>>> > process of 'try our best then deal with bug reports later').
>>>> >
>>>> > What do we think about this?
>>>> >
>>>> > Thanks,
>>>> > Troy
>>>> >
>>>> >
>>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>>>> wrote:
>>>> >>
>>>> >> Hey all,
>>>> >>
>>>> >> I know we have a number of outstanding JIRA issues, but I think most of
>>>> them have been handled for the 2.9.4 release? Do we have anything
>>>> outstanding that is holding back a new release?
>>>> >>
>>>> >> ~P
>>>> >
>>>>
>>>
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by Wyatt Barnett <wy...@gmail.com>.
Sweet, CI rocks.
Just ran through things in the aforementioned app that required some
search updates. 2.9.4 was a drop in replacement for the pre-offical
2.9.2. Search scores remained identical throughout the database, etc.
Release +1.
On Sun, Apr 10, 2011 at 5:17 PM, Michael Herndon
<mh...@wickedsoftware.net> wrote:
> Hudkins and plugins seems to work on the newest jenkins on windows 2008 r2.
>
> I'm just waiting on a signal that the folder structure has been been redone
> and finalized to move forward with geting a build script working on a local
> server 2008 R2 install. then submitting all the needs to get everything
> working on hudkins and server 2008 to infrastructure.
>
> On Sun, Apr 10, 2011 at 5:11 PM, Amanuel Workneh <am...@gmail.com> wrote:
>
>> Builds fine.
>>
>> Three failed tests,
>> Lucene.Net.Index.TestIndexWriterReader.TestDuringAddIndexes and
>> Lucene.Net.Index.TestIndexWriter.TestFutureCommit and
>> Lucene.Net.Store.TestWindowsMMap (MMapDirectory does not seem to be
>> ready for the world yet)
>>
>> Related: What is the Hudkins status?
>>
>>
>> On Tue, Apr 5, 2011 at 9:23 PM, Wyatt Barnett <wy...@gmail.com>
>> wrote:
>> > Tag [+1]
>> >
>> > svn export and command line build successful; I'll keep you all posted .
>> . .
>> >
>> > On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
>> >> Yes. Once we're ready to call this revision an RC, it should be tagged
>> as such.
>> >>
>> >> Wyatt: Thanks for helping to test! Looking forward to your results.
>> >>
>> >> Thanks,
>> >> Troy
>> >>
>> >>
>> >> On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
>> >> <ne...@thermofisher.com> wrote:
>> >>>
>> >>> No, the URL in DIGY's email apepars correct and the SVN revision
>> appears to be 1086410.
>> >>>
>> >>> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for
>> previous release candidates?
>> >>>
>> >>> - Neal
>> >>>
>> >>> -----Original Message-----
>> >>> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
>> >>> Sent: Tuesday, April 05, 2011 12:15 PM
>> >>> To: lucene-net-dev@lucene.apache.org
>> >>> Cc: digy digy
>> >>> Subject: Re: [Lucene.Net] release 2.9.4
>> >>>
>> >>> Thanks. For anyone watching, the corrected clickable link is
>> >>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
>> >>>
>> >>> Also, just to make sure we are looking at this right, the revision we
>> >>> should be using is 1089138 -- main thing is I've been in and out of
>> >>> town, not caught up on anything and I'd hate to start building stuff
>> >>> against the wrong version . .
>> >>>
>> >>> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
>> >>>> Sorry, no binaries. You can download the source from
>> >>>>
>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>> >>>>
>> >>>> DIGY
>> >>>>
>> >>>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <
>> wyatt.barnett@gmail.com>wrote:
>> >>>>
>> >>>>> Actually about to dive into a big search tweaking spike in a certain
>> >>>>> project here, happy to do it on 2.9.4. Got binaries?
>> >>>>>
>> >>>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com>
>> wrote:
>> >>>>> > We don't have any sort of QA report on the latest build. DIGY
>> called
>> >>>>> > for testing, but I haven't seen anyone respond to that request
>> >>>>> > indicating successful testing.
>> >>>>> >
>> >>>>> > So, how do we want to manage this?
>> >>>>> >
>> >>>>> > In the business world, we'd never think of making a release without
>> >>>>> > extensive QA first. In my other open source projects, either we've
>> >>>>> > managed QA ourselves by 'switching hats' for a couple weeks prior
>> to
>> >>>>> > release, or just crossed our fingers because the user base was too
>> >>>>> > small.
>> >>>>> >
>> >>>>> > Lucene.Net is a fairly high-profile project, with a large user
>> base. I
>> >>>>> > think it would not be responsible to make a release without a
>> formal
>> >>>>> > QA process. We do have extensive unit tests, but do you think those
>> >>>>> > are sufficient to cover our QA needs? Should we try to find
>> community
>> >>>>> > members with a specialty in software testing that would be willing
>> to
>> >>>>> > fulfill this role on our project? Should we just swap hats?
>> >>>>> >
>> >>>>> > I didn't worry about this issue with the latest 2.9.2 release
>> because
>> >>>>> > it was QAed by the user base for a long time before it was an
>> >>>>> > 'official release'. Maybe this is an effective tactic? Release
>> first,
>> >>>>> > and let the user base roll in bug reports fixing them on yet later
>> >>>>> > minor maintenance releases? This seems to be the method a lot of
>> >>>>> > projects use (i.e. no specific QA process, but rather an organic
>> >>>>> > process of 'try our best then deal with bug reports later').
>> >>>>> >
>> >>>>> > What do we think about this?
>> >>>>> >
>> >>>>> > Thanks,
>> >>>>> > Troy
>> >>>>> >
>> >>>>> >
>> >>>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <
>> geobmx540@hotmail.com>
>> >>>>> wrote:
>> >>>>> >>
>> >>>>> >> Hey all,
>> >>>>> >>
>> >>>>> >> I know we have a number of outstanding JIRA issues, but I think
>> most of
>> >>>>> them have been handled for the 2.9.4 release? Do we have anything
>> >>>>> outstanding that is holding back a new release?
>> >>>>> >>
>> >>>>> >> ~P
>> >>>>> >
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by Michael Herndon <mh...@wickedsoftware.net>.
Hudkins and plugins seems to work on the newest jenkins on windows 2008 r2.
I'm just waiting on a signal that the folder structure has been been redone
and finalized to move forward with geting a build script working on a local
server 2008 R2 install. then submitting all the needs to get everything
working on hudkins and server 2008 to infrastructure.
On Sun, Apr 10, 2011 at 5:11 PM, Amanuel Workneh <am...@gmail.com> wrote:
> Builds fine.
>
> Three failed tests,
> Lucene.Net.Index.TestIndexWriterReader.TestDuringAddIndexes and
> Lucene.Net.Index.TestIndexWriter.TestFutureCommit and
> Lucene.Net.Store.TestWindowsMMap (MMapDirectory does not seem to be
> ready for the world yet)
>
> Related: What is the Hudkins status?
>
>
> On Tue, Apr 5, 2011 at 9:23 PM, Wyatt Barnett <wy...@gmail.com>
> wrote:
> > Tag [+1]
> >
> > svn export and command line build successful; I'll keep you all posted .
> . .
> >
> > On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
> >> Yes. Once we're ready to call this revision an RC, it should be tagged
> as such.
> >>
> >> Wyatt: Thanks for helping to test! Looking forward to your results.
> >>
> >> Thanks,
> >> Troy
> >>
> >>
> >> On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
> >> <ne...@thermofisher.com> wrote:
> >>>
> >>> No, the URL in DIGY's email apepars correct and the SVN revision
> appears to be 1086410.
> >>>
> >>> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for
> previous release candidates?
> >>>
> >>> - Neal
> >>>
> >>> -----Original Message-----
> >>> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
> >>> Sent: Tuesday, April 05, 2011 12:15 PM
> >>> To: lucene-net-dev@lucene.apache.org
> >>> Cc: digy digy
> >>> Subject: Re: [Lucene.Net] release 2.9.4
> >>>
> >>> Thanks. For anyone watching, the corrected clickable link is
> >>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
> >>>
> >>> Also, just to make sure we are looking at this right, the revision we
> >>> should be using is 1089138 -- main thing is I've been in and out of
> >>> town, not caught up on anything and I'd hate to start building stuff
> >>> against the wrong version . .
> >>>
> >>> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
> >>>> Sorry, no binaries. You can download the source from
> >>>>
> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
> >>>>
> >>>> DIGY
> >>>>
> >>>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <
> wyatt.barnett@gmail.com>wrote:
> >>>>
> >>>>> Actually about to dive into a big search tweaking spike in a certain
> >>>>> project here, happy to do it on 2.9.4. Got binaries?
> >>>>>
> >>>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com>
> wrote:
> >>>>> > We don't have any sort of QA report on the latest build. DIGY
> called
> >>>>> > for testing, but I haven't seen anyone respond to that request
> >>>>> > indicating successful testing.
> >>>>> >
> >>>>> > So, how do we want to manage this?
> >>>>> >
> >>>>> > In the business world, we'd never think of making a release without
> >>>>> > extensive QA first. In my other open source projects, either we've
> >>>>> > managed QA ourselves by 'switching hats' for a couple weeks prior
> to
> >>>>> > release, or just crossed our fingers because the user base was too
> >>>>> > small.
> >>>>> >
> >>>>> > Lucene.Net is a fairly high-profile project, with a large user
> base. I
> >>>>> > think it would not be responsible to make a release without a
> formal
> >>>>> > QA process. We do have extensive unit tests, but do you think those
> >>>>> > are sufficient to cover our QA needs? Should we try to find
> community
> >>>>> > members with a specialty in software testing that would be willing
> to
> >>>>> > fulfill this role on our project? Should we just swap hats?
> >>>>> >
> >>>>> > I didn't worry about this issue with the latest 2.9.2 release
> because
> >>>>> > it was QAed by the user base for a long time before it was an
> >>>>> > 'official release'. Maybe this is an effective tactic? Release
> first,
> >>>>> > and let the user base roll in bug reports fixing them on yet later
> >>>>> > minor maintenance releases? This seems to be the method a lot of
> >>>>> > projects use (i.e. no specific QA process, but rather an organic
> >>>>> > process of 'try our best then deal with bug reports later').
> >>>>> >
> >>>>> > What do we think about this?
> >>>>> >
> >>>>> > Thanks,
> >>>>> > Troy
> >>>>> >
> >>>>> >
> >>>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <
> geobmx540@hotmail.com>
> >>>>> wrote:
> >>>>> >>
> >>>>> >> Hey all,
> >>>>> >>
> >>>>> >> I know we have a number of outstanding JIRA issues, but I think
> most of
> >>>>> them have been handled for the 2.9.4 release? Do we have anything
> >>>>> outstanding that is holding back a new release?
> >>>>> >>
> >>>>> >> ~P
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [Lucene.Net] release 2.9.4
Posted by Amanuel Workneh <am...@gmail.com>.
Builds fine.
Three failed tests,
Lucene.Net.Index.TestIndexWriterReader.TestDuringAddIndexes and
Lucene.Net.Index.TestIndexWriter.TestFutureCommit and
Lucene.Net.Store.TestWindowsMMap (MMapDirectory does not seem to be
ready for the world yet)
Related: What is the Hudkins status?
On Tue, Apr 5, 2011 at 9:23 PM, Wyatt Barnett <wy...@gmail.com> wrote:
> Tag [+1]
>
> svn export and command line build successful; I'll keep you all posted . . .
>
> On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
>> Yes. Once we're ready to call this revision an RC, it should be tagged as such.
>>
>> Wyatt: Thanks for helping to test! Looking forward to your results.
>>
>> Thanks,
>> Troy
>>
>>
>> On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
>> <ne...@thermofisher.com> wrote:
>>>
>>> No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
>>>
>>> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates?
>>>
>>> - Neal
>>>
>>> -----Original Message-----
>>> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
>>> Sent: Tuesday, April 05, 2011 12:15 PM
>>> To: lucene-net-dev@lucene.apache.org
>>> Cc: digy digy
>>> Subject: Re: [Lucene.Net] release 2.9.4
>>>
>>> Thanks. For anyone watching, the corrected clickable link is
>>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
>>>
>>> Also, just to make sure we are looking at this right, the revision we
>>> should be using is 1089138 -- main thing is I've been in and out of
>>> town, not caught up on anything and I'd hate to start building stuff
>>> against the wrong version . .
>>>
>>> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
>>>> Sorry, no binaries. You can download the source from
>>>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>>>>
>>>> DIGY
>>>>
>>>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>>>>
>>>>> Actually about to dive into a big search tweaking spike in a certain
>>>>> project here, happy to do it on 2.9.4. Got binaries?
>>>>>
>>>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>>>>> > We don't have any sort of QA report on the latest build. DIGY called
>>>>> > for testing, but I haven't seen anyone respond to that request
>>>>> > indicating successful testing.
>>>>> >
>>>>> > So, how do we want to manage this?
>>>>> >
>>>>> > In the business world, we'd never think of making a release without
>>>>> > extensive QA first. In my other open source projects, either we've
>>>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>>>>> > release, or just crossed our fingers because the user base was too
>>>>> > small.
>>>>> >
>>>>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>>>>> > think it would not be responsible to make a release without a formal
>>>>> > QA process. We do have extensive unit tests, but do you think those
>>>>> > are sufficient to cover our QA needs? Should we try to find community
>>>>> > members with a specialty in software testing that would be willing to
>>>>> > fulfill this role on our project? Should we just swap hats?
>>>>> >
>>>>> > I didn't worry about this issue with the latest 2.9.2 release because
>>>>> > it was QAed by the user base for a long time before it was an
>>>>> > 'official release'. Maybe this is an effective tactic? Release first,
>>>>> > and let the user base roll in bug reports fixing them on yet later
>>>>> > minor maintenance releases? This seems to be the method a lot of
>>>>> > projects use (i.e. no specific QA process, but rather an organic
>>>>> > process of 'try our best then deal with bug reports later').
>>>>> >
>>>>> > What do we think about this?
>>>>> >
>>>>> > Thanks,
>>>>> > Troy
>>>>> >
>>>>> >
>>>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Hey all,
>>>>> >>
>>>>> >> I know we have a number of outstanding JIRA issues, but I think most of
>>>>> them have been handled for the 2.9.4 release? Do we have anything
>>>>> outstanding that is holding back a new release?
>>>>> >>
>>>>> >> ~P
>>>>> >
>>>>>
>>>>
>>>
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by Wyatt Barnett <wy...@gmail.com>.
Tag [+1]
svn export and command line build successful; I'll keep you all posted . . .
On Tue, Apr 5, 2011 at 3:07 PM, Troy Howard <th...@gmail.com> wrote:
> Yes. Once we're ready to call this revision an RC, it should be tagged as such.
>
> Wyatt: Thanks for helping to test! Looking forward to your results.
>
> Thanks,
> Troy
>
>
> On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
> <ne...@thermofisher.com> wrote:
>>
>> No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
>>
>> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates?
>>
>> - Neal
>>
>> -----Original Message-----
>> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
>> Sent: Tuesday, April 05, 2011 12:15 PM
>> To: lucene-net-dev@lucene.apache.org
>> Cc: digy digy
>> Subject: Re: [Lucene.Net] release 2.9.4
>>
>> Thanks. For anyone watching, the corrected clickable link is
>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
>>
>> Also, just to make sure we are looking at this right, the revision we
>> should be using is 1089138 -- main thing is I've been in and out of
>> town, not caught up on anything and I'd hate to start building stuff
>> against the wrong version . .
>>
>> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
>>> Sorry, no binaries. You can download the source from
>>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>>>
>>> DIGY
>>>
>>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>>>
>>>> Actually about to dive into a big search tweaking spike in a certain
>>>> project here, happy to do it on 2.9.4. Got binaries?
>>>>
>>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>>>> > We don't have any sort of QA report on the latest build. DIGY called
>>>> > for testing, but I haven't seen anyone respond to that request
>>>> > indicating successful testing.
>>>> >
>>>> > So, how do we want to manage this?
>>>> >
>>>> > In the business world, we'd never think of making a release without
>>>> > extensive QA first. In my other open source projects, either we've
>>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>>>> > release, or just crossed our fingers because the user base was too
>>>> > small.
>>>> >
>>>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>>>> > think it would not be responsible to make a release without a formal
>>>> > QA process. We do have extensive unit tests, but do you think those
>>>> > are sufficient to cover our QA needs? Should we try to find community
>>>> > members with a specialty in software testing that would be willing to
>>>> > fulfill this role on our project? Should we just swap hats?
>>>> >
>>>> > I didn't worry about this issue with the latest 2.9.2 release because
>>>> > it was QAed by the user base for a long time before it was an
>>>> > 'official release'. Maybe this is an effective tactic? Release first,
>>>> > and let the user base roll in bug reports fixing them on yet later
>>>> > minor maintenance releases? This seems to be the method a lot of
>>>> > projects use (i.e. no specific QA process, but rather an organic
>>>> > process of 'try our best then deal with bug reports later').
>>>> >
>>>> > What do we think about this?
>>>> >
>>>> > Thanks,
>>>> > Troy
>>>> >
>>>> >
>>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>>>> wrote:
>>>> >>
>>>> >> Hey all,
>>>> >>
>>>> >> I know we have a number of outstanding JIRA issues, but I think most of
>>>> them have been handled for the 2.9.4 release? Do we have anything
>>>> outstanding that is holding back a new release?
>>>> >>
>>>> >> ~P
>>>> >
>>>>
>>>
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by Troy Howard <th...@gmail.com>.
Yes. Once we're ready to call this revision an RC, it should be tagged as such.
Wyatt: Thanks for helping to test! Looking forward to your results.
Thanks,
Troy
On Tue, Apr 5, 2011 at 11:37 AM, Granroth, Neal V.
<ne...@thermofisher.com> wrote:
>
> No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
>
> Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates?
>
> - Neal
>
> -----Original Message-----
> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
> Sent: Tuesday, April 05, 2011 12:15 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: digy digy
> Subject: Re: [Lucene.Net] release 2.9.4
>
> Thanks. For anyone watching, the corrected clickable link is
> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
>
> Also, just to make sure we are looking at this right, the revision we
> should be using is 1089138 -- main thing is I've been in and out of
> town, not caught up on anything and I'd hate to start building stuff
> against the wrong version . .
>
> On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
>> Sorry, no binaries. You can download the source from
>> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>>
>> DIGY
>>
>> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>>
>>> Actually about to dive into a big search tweaking spike in a certain
>>> project here, happy to do it on 2.9.4. Got binaries?
>>>
>>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>>> > We don't have any sort of QA report on the latest build. DIGY called
>>> > for testing, but I haven't seen anyone respond to that request
>>> > indicating successful testing.
>>> >
>>> > So, how do we want to manage this?
>>> >
>>> > In the business world, we'd never think of making a release without
>>> > extensive QA first. In my other open source projects, either we've
>>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>>> > release, or just crossed our fingers because the user base was too
>>> > small.
>>> >
>>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>>> > think it would not be responsible to make a release without a formal
>>> > QA process. We do have extensive unit tests, but do you think those
>>> > are sufficient to cover our QA needs? Should we try to find community
>>> > members with a specialty in software testing that would be willing to
>>> > fulfill this role on our project? Should we just swap hats?
>>> >
>>> > I didn't worry about this issue with the latest 2.9.2 release because
>>> > it was QAed by the user base for a long time before it was an
>>> > 'official release'. Maybe this is an effective tactic? Release first,
>>> > and let the user base roll in bug reports fixing them on yet later
>>> > minor maintenance releases? This seems to be the method a lot of
>>> > projects use (i.e. no specific QA process, but rather an organic
>>> > process of 'try our best then deal with bug reports later').
>>> >
>>> > What do we think about this?
>>> >
>>> > Thanks,
>>> > Troy
>>> >
>>> >
>>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>>> wrote:
>>> >>
>>> >> Hey all,
>>> >>
>>> >> I know we have a number of outstanding JIRA issues, but I think most of
>>> them have been handled for the 2.9.4 release? Do we have anything
>>> outstanding that is holding back a new release?
>>> >>
>>> >> ~P
>>> >
>>>
>>
>
RE: [Lucene.Net] release 2.9.4
Posted by "Granroth, Neal V." <ne...@thermofisher.com>.
No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates?
- Neal
-----Original Message-----
From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
Sent: Tuesday, April 05, 2011 12:15 PM
To: lucene-net-dev@lucene.apache.org
Cc: digy digy
Subject: Re: [Lucene.Net] release 2.9.4
Thanks. For anyone watching, the corrected clickable link is
https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
Also, just to make sure we are looking at this right, the revision we
should be using is 1089138 -- main thing is I've been in and out of
town, not caught up on anything and I'd hate to start building stuff
against the wrong version . .
On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
> Sorry, no binaries. You can download the source from
> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>
> DIGY
>
> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>
>> Actually about to dive into a big search tweaking spike in a certain
>> project here, happy to do it on 2.9.4. Got binaries?
>>
>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>> > We don't have any sort of QA report on the latest build. DIGY called
>> > for testing, but I haven't seen anyone respond to that request
>> > indicating successful testing.
>> >
>> > So, how do we want to manage this?
>> >
>> > In the business world, we'd never think of making a release without
>> > extensive QA first. In my other open source projects, either we've
>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>> > release, or just crossed our fingers because the user base was too
>> > small.
>> >
>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>> > think it would not be responsible to make a release without a formal
>> > QA process. We do have extensive unit tests, but do you think those
>> > are sufficient to cover our QA needs? Should we try to find community
>> > members with a specialty in software testing that would be willing to
>> > fulfill this role on our project? Should we just swap hats?
>> >
>> > I didn't worry about this issue with the latest 2.9.2 release because
>> > it was QAed by the user base for a long time before it was an
>> > 'official release'. Maybe this is an effective tactic? Release first,
>> > and let the user base roll in bug reports fixing them on yet later
>> > minor maintenance releases? This seems to be the method a lot of
>> > projects use (i.e. no specific QA process, but rather an organic
>> > process of 'try our best then deal with bug reports later').
>> >
>> > What do we think about this?
>> >
>> > Thanks,
>> > Troy
>> >
>> >
>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>> wrote:
>> >>
>> >> Hey all,
>> >>
>> >> I know we have a number of outstanding JIRA issues, but I think most of
>> them have been handled for the 2.9.4 release? Do we have anything
>> outstanding that is holding back a new release?
>> >>
>> >> ~P
>> >
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by Wyatt Barnett <wy...@gmail.com>.
Thanks. For anyone watching, the corrected clickable link is
https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/.
Also, just to make sure we are looking at this right, the revision we
should be using is 1089138 -- main thing is I've been in and out of
town, not caught up on anything and I'd hate to start building stuff
against the wrong version . .
On Tue, Apr 5, 2011 at 1:10 PM, digy digy <di...@gmail.com> wrote:
> Sorry, no binaries. You can download the source from
> https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
>
> DIGY
>
> On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
>
>> Actually about to dive into a big search tweaking spike in a certain
>> project here, happy to do it on 2.9.4. Got binaries?
>>
>> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
>> > We don't have any sort of QA report on the latest build. DIGY called
>> > for testing, but I haven't seen anyone respond to that request
>> > indicating successful testing.
>> >
>> > So, how do we want to manage this?
>> >
>> > In the business world, we'd never think of making a release without
>> > extensive QA first. In my other open source projects, either we've
>> > managed QA ourselves by 'switching hats' for a couple weeks prior to
>> > release, or just crossed our fingers because the user base was too
>> > small.
>> >
>> > Lucene.Net is a fairly high-profile project, with a large user base. I
>> > think it would not be responsible to make a release without a formal
>> > QA process. We do have extensive unit tests, but do you think those
>> > are sufficient to cover our QA needs? Should we try to find community
>> > members with a specialty in software testing that would be willing to
>> > fulfill this role on our project? Should we just swap hats?
>> >
>> > I didn't worry about this issue with the latest 2.9.2 release because
>> > it was QAed by the user base for a long time before it was an
>> > 'official release'. Maybe this is an effective tactic? Release first,
>> > and let the user base roll in bug reports fixing them on yet later
>> > minor maintenance releases? This seems to be the method a lot of
>> > projects use (i.e. no specific QA process, but rather an organic
>> > process of 'try our best then deal with bug reports later').
>> >
>> > What do we think about this?
>> >
>> > Thanks,
>> > Troy
>> >
>> >
>> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
>> wrote:
>> >>
>> >> Hey all,
>> >>
>> >> I know we have a number of outstanding JIRA issues, but I think most of
>> them have been handled for the 2.9.4 release? Do we have anything
>> outstanding that is holding back a new release?
>> >>
>> >> ~P
>> >
>>
>
Re: [Lucene.Net] release 2.9.4
Posted by digy digy <di...@gmail.com>.
Sorry, no binaries. You can download the source from
https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net
DIGY
On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wy...@gmail.com>wrote:
> Actually about to dive into a big search tweaking spike in a certain
> project here, happy to do it on 2.9.4. Got binaries?
>
> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
> > We don't have any sort of QA report on the latest build. DIGY called
> > for testing, but I haven't seen anyone respond to that request
> > indicating successful testing.
> >
> > So, how do we want to manage this?
> >
> > In the business world, we'd never think of making a release without
> > extensive QA first. In my other open source projects, either we've
> > managed QA ourselves by 'switching hats' for a couple weeks prior to
> > release, or just crossed our fingers because the user base was too
> > small.
> >
> > Lucene.Net is a fairly high-profile project, with a large user base. I
> > think it would not be responsible to make a release without a formal
> > QA process. We do have extensive unit tests, but do you think those
> > are sufficient to cover our QA needs? Should we try to find community
> > members with a specialty in software testing that would be willing to
> > fulfill this role on our project? Should we just swap hats?
> >
> > I didn't worry about this issue with the latest 2.9.2 release because
> > it was QAed by the user base for a long time before it was an
> > 'official release'. Maybe this is an effective tactic? Release first,
> > and let the user base roll in bug reports fixing them on yet later
> > minor maintenance releases? This seems to be the method a lot of
> > projects use (i.e. no specific QA process, but rather an organic
> > process of 'try our best then deal with bug reports later').
> >
> > What do we think about this?
> >
> > Thanks,
> > Troy
> >
> >
> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com>
> wrote:
> >>
> >> Hey all,
> >>
> >> I know we have a number of outstanding JIRA issues, but I think most of
> them have been handled for the 2.9.4 release? Do we have anything
> outstanding that is holding back a new release?
> >>
> >> ~P
> >
>
Re: [Lucene.Net] release 2.9.4
Posted by Wyatt Barnett <wy...@gmail.com>.
Actually about to dive into a big search tweaking spike in a certain
project here, happy to do it on 2.9.4. Got binaries?
On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <th...@gmail.com> wrote:
> We don't have any sort of QA report on the latest build. DIGY called
> for testing, but I haven't seen anyone respond to that request
> indicating successful testing.
>
> So, how do we want to manage this?
>
> In the business world, we'd never think of making a release without
> extensive QA first. In my other open source projects, either we've
> managed QA ourselves by 'switching hats' for a couple weeks prior to
> release, or just crossed our fingers because the user base was too
> small.
>
> Lucene.Net is a fairly high-profile project, with a large user base. I
> think it would not be responsible to make a release without a formal
> QA process. We do have extensive unit tests, but do you think those
> are sufficient to cover our QA needs? Should we try to find community
> members with a specialty in software testing that would be willing to
> fulfill this role on our project? Should we just swap hats?
>
> I didn't worry about this issue with the latest 2.9.2 release because
> it was QAed by the user base for a long time before it was an
> 'official release'. Maybe this is an effective tactic? Release first,
> and let the user base roll in bug reports fixing them on yet later
> minor maintenance releases? This seems to be the method a lot of
> projects use (i.e. no specific QA process, but rather an organic
> process of 'try our best then deal with bug reports later').
>
> What do we think about this?
>
> Thanks,
> Troy
>
>
> On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com> wrote:
>>
>> Hey all,
>>
>> I know we have a number of outstanding JIRA issues, but I think most of them have been handled for the 2.9.4 release? Do we have anything outstanding that is holding back a new release?
>>
>> ~P
>
Re: [Lucene.Net] release 2.9.4
Posted by Troy Howard <th...@gmail.com>.
We don't have any sort of QA report on the latest build. DIGY called
for testing, but I haven't seen anyone respond to that request
indicating successful testing.
So, how do we want to manage this?
In the business world, we'd never think of making a release without
extensive QA first. In my other open source projects, either we've
managed QA ourselves by 'switching hats' for a couple weeks prior to
release, or just crossed our fingers because the user base was too
small.
Lucene.Net is a fairly high-profile project, with a large user base. I
think it would not be responsible to make a release without a formal
QA process. We do have extensive unit tests, but do you think those
are sufficient to cover our QA needs? Should we try to find community
members with a specialty in software testing that would be willing to
fulfill this role on our project? Should we just swap hats?
I didn't worry about this issue with the latest 2.9.2 release because
it was QAed by the user base for a long time before it was an
'official release'. Maybe this is an effective tactic? Release first,
and let the user base roll in bug reports fixing them on yet later
minor maintenance releases? This seems to be the method a lot of
projects use (i.e. no specific QA process, but rather an organic
process of 'try our best then deal with bug reports later').
What do we think about this?
Thanks,
Troy
On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <ge...@hotmail.com> wrote:
>
> Hey all,
>
> I know we have a number of outstanding JIRA issues, but I think most of them have been handled for the 2.9.4 release? Do we have anything outstanding that is holding back a new release?
>
> ~P