Hi,

Those 45 minutes is a build and lots of tests executing (net451), and it
fails for tests involving netcoreapp1.0.

It looks like I am running with "dotnet --version" 1.0.3. Executing the
".\build\dotnet-install.ps1 -Version 1.0.0-preview2-1-003177" does
successfully change "dotnet --version" to 1.0.0-preview2-1-003177. I
need to do this _before_ calling ".\build.bat -t" and the tests _starts_.

I am now running into issues with references to Microsoft.NETCore.App
1.0.1, but I believe those are already fixed in a later commit by you,
and part of the beta2 release. I'll focus on that release from now on.
Ref: http://git-wip-us.apache.org/repos/asf/lucenenet/commit/c2bf370f

See you in the beta 2 vote thread. ;)

// Simon


On 2017-05-09 19:02, Shad Storhaug wrote:
> Simon,
> 
> You did the right thing by abstaining. I am still trying to pin down what is 
> happening here, as I am unable to reproduce it.
> 
> You mentioned the build took 45 minutes for it to fail during testing. On a 
> fast machine, that probably means that the run of the .NET Core tests was 
> successful, and the .NET Framework tests failed since they run in that order. 
> It is strange that it is unable to resolve the paths halfway through the test 
> run though (since we are using the nunit test runner for those tests, I would 
> expect the problem to be related to that), but the way the paths are being 
> resolved isn't exactly bullet-proof:
> 
> pushd $base_directory
> $testProjects = Get-ChildItem -Path "project.json" -Recurse | ? { 
> $_.Directory.Name.Contains(".Tests") }
> Popd
> 
> If you are familiar with Powershell, could you work with the script to see 
> (if and) why the paths are not resolving? You can make the script run in a 
> few seconds by temporarily commenting everything inside of an Exec { } block.
> 
> Thanks,
> Shad Storhaug (NightOwl888)
> 
> -----Original Message-----
> From: Simon Svensson [mailto:[email protected]] 
> Sent: Tuesday, May 9, 2017 2:40 PM
> To: [email protected]
> Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
> 
> Hi,
> 
> I'm positive to a release, but since someone recently linked the release 
> process, and I read it, I cannot give a vote since I am unable to comply with 
> the requirements.
> 
> I'm clearly missing something on my local machine, but I do not yet know 
> what. I installed the 4.5.1 Dev Pack you linked, but still same failures. I 
> havn't looked into it further due to time/competence constraints on my part.
> 
> It's the "..., compile as provided, and test the result on their own 
> platform." that alludes me:
> 
>> "Before casting +1 binding votes, individuals are REQUIRED to download
> all signed source code packages onto their own hardware, verify that they 
> meet all requirements of ASF policy on releases as described below, validate 
> all cryptographic signatures, compile as provided, and test the result on 
> their own platform."
> 
> Source: https://www.apache.org/legal/release-policy.html#release-approval
> 
> // Simon
> 
> On 2017-05-09 03:17, Shad Storhaug wrote:
>> It has now been 72 hours since this vote started. Here are the results:
>>
>> PMC votes:
>>
>> +1: (3)
>> 0: (0)
>> -1: (1)
>>
>> Non-PMC votes:
>> +1: (7) (2 of them committers)
>> 0: (0)
>> -1: (0)
>>
>> We also heard from Simon Svensson about an issue running tests on the CLI, 
>> but he did not vote. Technically, he was running the tests from the 
>> repository, not from the release package. I did some investigation and on a 
>> clean system without .NET or Visual Studio installed it fails to compile in 
>> that configuration. It looks like some of the references are using reference 
>> assemblies, when I believe they should be using NuGet packages that download 
>> on demand. So, for the time being having the .NET Framework 4.5.1 Developer 
>> Pack installed is a prerequisite for building 
>> (https://www.microsoft.com/en-us/download/details.aspx?id=40772).
>>
>> I have also confirmed that attempting to build/test with Powershell 2.0 does 
>> not work. I am testing with 3.0 now (so far it is working), but suffice to 
>> say the newer the Powershell version the better.
>>
>> As for testing, this can be done either with Visual Studio 2015: 
>> http://apache.markmail.org/search/?q=from%3A%22Shad+Storhaug%22#query:
>> from%3A%22Shad%20Storhaug%22+page:1+mid:yhrjkuo7kcxougpz+state:results
>>
>> Or, from the command line using this command:
>>
>> powershell -ExecutionPolicy Bypass -Command "Import-Module 
>> .\build\psake.psm1; Invoke-Psake .\build\build.ps1 -Task Default,Test 
>> -Properties @{prepareForBuild='false';backup_files='false'}"
>>
>> We should add a switch to build.bat to make that command simpler (i.e. build 
>> -t), but that is how you can run the tests this time around.
>>
>> ----------------------------------------------------------------------
>> ---------------------------------------------------------------
>>
>> 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?
>>
>> Thanks,
>> Shad Storhaug (NightOwl888)
>>
>>
>>
>> -----Original Message-----
>> From: Shad Storhaug
>> Sent: Tuesday, May 9, 2017 4:35 AM
>> To: [email protected]
>> Subject: RE: [Vote] Apache Lucene.Net 4.8.0-beta00001
>>
>> Itamar,
>>
>> Thanks for your valuable opinion, but I respectfully disagree.
>>
>> The main purpose of getting this into the wild is so we can turn the trickle 
>> of bug reports and pull requests into a flood. We know there are bugs (there 
>> are still at least a dozen flakey tests, some of them concurrency related). 
>> But it would take forever to fix them if we had to patch them one at a time, 
>> cancel the release, fix the next one, cancel the next release, and so on.
>>
>> As for users being discouraged, I can't imagine the situation being worse 
>> than the 51 users a day downloading these packages: 
>>
>> https://www.nuget.org/packages/Lucene.Net.Core/
>> https://www.nuget.org/packages/Lucene.Net.Analysis.Common/
>>
>> Not only do the unsuspecting downloaders not realize that they are 
>> unofficial packages, but they are versioned as full releases, despite being 
>> unstable. Anyone who adapts that API is going to be disappointed with the 
>> amount of rework they need to do to use the official one. Waiting another 72 
>> hours means another 153 potentially discouraged users who think they are 
>> using production-ready code, whereas releasing the beta immediately means 
>> those who knowingly decide to push pre-release code into production may or 
>> may not be discouraged by this bug. In all likelihood, the patch will be out 
>> before they are ready to release anyway.
>>
>> IMO, we should push this release forward so we can start collecting 
>> information on what is broken, recruit some help to fix the bugs, and fully 
>> expect to have another release in short order (with more than just this one 
>> patch in it). That's my 2 cents.
>>
>> Thanks,
>> Shad Storhaug (NightOwl888)
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] 
>> On Behalf Of Itamar Syn-Hershko
>> Sent: Tuesday, May 9, 2017 2:31 AM
>> To: [email protected]
>> Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
>>
>> Shad, Connie and team - great work on this, happy to see us reaching this 
>> stage.
>>
>> I'm voting -1, reason is I think our first public beta should incorporate 
>> this fix: https://github.com/apache/lucenenet/pull/205. This one is 
>> important, every real-world use case would hit this issue one way or another 
>> (and I'm expecting our users to run multi-threaded), and I wouldn't want to 
>> discourage them from trying future versions by running into this bug, which 
>> I consider rather severe. Let's make this beta count, and waiting another 72 
>> hours wouldn't change much.
>>
>> I will be happy to support the efforts of preparing a fixed version and 
>> pushing it towards another vote and release.
>>
>> --
>>
>> 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 Mon, May 8, 2017 at 6:38 PM, Prescott Nasser 
>> <[email protected]>
>> wrote:
>>
>>> Lazaro, you can send an email to [email protected]
>>> from your subscribed email to unsubscribe.
>>> ________________________________
>>> From: Lazaro Fernandes Lima <[email protected]>
>>> Sent: Monday, May 8, 2017 6:45:39 AM
>>> To: [email protected]
>>> Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00001
>>>
>>> unsubscribe, please
>>>
>>> 2017-05-08 10:40 GMT-03:00 John Duerden <[email protected]>:
>>>
>>>> Downloaded and ran beta on a site I support - worked fine.
>>>>
>>>> Not sure my vote counts but +1 here and thanks for all the work.
>>>>
>>>> John Duerden
>>>>
>>>> On 5 May 2017 at 18:15, Shad Storhaug <[email protected]> wrote:
>>>>
>>>>> So, after 4 1/2 years of silence, we are ready to shake up the 
>>>>> world
>>> with
>>>>> a new version of Lucene.Net.
>>>>>
>>>>>
>>>>> The source and binary packages are available for inspection at:
>>>>> https://dist.apache.org/repos/dist/dev/lucenenet/.
>>>>>
>>>>> There is a MyGet feed that can be accessed at:
>>>>> V2: https://www.myget.org/F/lucene-net-nuget/api/v2 (VS2012+)
>>>>> V3: https://www.myget.org/F/lucene-net-nuget/api/v3/index.json
>>> (VS2015+)
>>>>>
>>>>> The tag is: https://github.com/apache/lucenenet/releases/tag/Lucene.
>>>>> Net_4_8_0_beta00001
>>>>>
>>>>>
>>>>> Please review the beta and vote.
>>>>> This vote will close no sooner than 72 hours from now, i.e. 
>>>>> sometime after 00:00 UTC 9-May 2017
>>>>>
>>>>> +1 - lets rock
>>>>> 0 - indifferent
>>>>> -1 - Not ready, because...
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Shad Storhaug (NightOwl888)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Prescott Nasser [mailto:[email protected]]
>>>>> Sent: Saturday, May 6, 2017 12:41 AM
>>>>> To: [email protected]
>>>>> Subject: RE: Release
>>>>>
>>>>> 3 is the only one I see that we should correct prior to beta. The 
>>>>> other three are all fixable as we go through beta with the community.
>>>>>
>>>>> I don't think ChineseAnalyzer needs to be done in this beta either. 
>>>>> We
>>>>> *should* release another beta with changes.txt, and the other fixes.
>>>>> ChineseAnalyzer can be included in the next beta as well as other
>>> issues
>>>>> seen by the community.
>>>>>
>>>>> I'd say fix 3, and I'll +1 a vote (72 hours). Between the 72hr 
>>>>> period
>>> and
>>>>> and the fix, Itamar probably has his week, and unless he find's a 
>>>>> huge issue, we can always address it in beta (sorry Itamar, I don't 
>>>>> think we have to wait for your review).
>>>>>
>>>>> My $.02.
>>>>>
>>>>> ~P
>>>>>
>>>>> -----Original Message-----
>>>>> From: Shad Storhaug [mailto:[email protected]]
>>>>> Sent: Friday, May 5, 2017 10:17 AM
>>>>> To: [email protected]
>>>>> Subject: RE: Release
>>>>>
>>>>> Okay, so it looks like we are back to square 1 then...
>>>>>
>>>>> Over the past few days I realized there are a few things that could 
>>>>> use some tweaking before the release:
>>>>>
>>>>> 1. The CHANGES.txt has not been updated with the latest status.
>>>>> 2. We have no way to make a strong-named build as per Itamar's blog
>>> post
>>>> (
>>>>> http://code972.com/blog/2014/04/68-ditching-strong-naming-
>>> for-lucene-net
>>>> ).
>>>>> 3. It might be better to rename the Lucene.Net.Icu package to 
>>>>> Lucene.Net.ICU (which, if done, is something that should be done 
>>>>> now,
>>> not
>>>>> after the first beta). Note this is an "extra" package that 
>>>>> doesn't
>>> exist
>>>>> in Java. Its purpose is to remove the icu.net dependency (that is 
>>>>> a
>>> PITA
>>>>> and doesn't yet have official .NET Core support) from the more 
>>>>> popular packages Lucene.Net.Analysis.Common and Lucene.Net.Highlighter.
>>>>> 4. The Spatial4n.Core and (unreleased) Spatial4n.Core.NTS packages
>>> depend
>>>>> on .NET Standard 1.6.1, but Lucene.Net depends on .NET Standard 1.6.0.
>>>> This
>>>>> causes a non-fatal dependency warning. But we need to update all 3 
>>>>> of
>>> the
>>>>> Spatial4n.Core, Spatial4n.Core.NTS, and Lucene.Net.Spatial to fix it.
>>>>>
>>>>> Of course, none of this is absolutely critical for the release.
>>> Opinions
>>>>> on whether we should hold up to address these issues (I know this 
>>>>> isn't
>>>> the
>>>>> "official" vote...just a question)?
>>>>>
>>>>> Itamar, I noticed you assigned yourself to the ChineseAnalyzer 
>>>>> task. Is that something you want to complete before the first 
>>>>> beta? Bear in mind that we will probably need to release fairly 
>>>>> frequently at first as bug reports come in and are addressed.
>>>>>
>>>>> Also, you mentioned "over the next week or so" for the review. Not
>>>> opposed
>>>>> to waiting for you to do your thing, but I am just trying to 
>>>>> ensure we reserve all of the NuGet package IDs before any of the 
>>>>> other ones are snagged. I suppose I could upload some dummy 
>>>>> packages to ensure it
>>>> doesn't
>>>>> happen again...
>>>>>
>>>>> The main purposes of the beta release on NuGet will be:
>>>>>
>>>>> 1. To get feedback and bug reports 2. To make [more of] the public 
>>>>> aware that we are now in beta 3. To recruit more help for 
>>>>> completion/optimization/stabilization
>>>>>
>>>>> Thanks,
>>>>> Shad Storhaug (NightOwl888)
>>>>>
>>>>>
>>>>> On Fri, May 5, 2017 at 10:29 AM, Stefan Bodewig 
>>>>> <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> On 2017-05-05, Shad Storhaug wrote:
>>>>>>
>>>>>>> It has been 72 hours since your reply, yet the packages are 
>>>>>>> still
>>> at
>>>>>>> the URL below and not at
>>>>>>> https://dist.apache.org/repos/dist/release/lucenenet/.
>>>>>>
>>>>>> Ah, my fault. I just threw out a link and didn't explain the 
>>>>>> process, I'm sorry.
>>>>>>
>>>>>> tldr; you must actively call for a vote.
>>>>>>
>>>>>> Cutting a release is a bit more complex at the ASF than in many 
>>>>>> other places. It may look cumbersome but is so in order to 
>>>>>> legally protect those who create the release. A release that has 
>>>>>> been approved by the PMC is an act of the foundation, so anybody 
>>>>>> trying to drag you into court because of the releases content, 
>>>>>> would end up facing the ASF, not you.
>>>>>>
>>>>>> For all the glory see http://www.apache.org/legal/
>>> release-policy.html
>>>>>> or just read along for the short version.
>>>>>>
>>>>>> That being said, we need to formally vote on the release and we 
>>>>>> need at least three PMC members to cast a +1 vote and more PMC 
>>>>>> members casting a
>>>>>> +1 than -1s.
>>>>>>
>>>>>> The 72 hours start once the release manager has sent out the 
>>>>>> VOTE email, for an example see
>>>>>> https://lists.apache.org/thread.html/952a831da7e32103ceade2a2f70
>>>>>> d99
>>>>>> f4e297861e0938fcfcf52955e1@1349569519@%3Cdev.lucenenet.apache.or
>>>>>> g%3E for the last time we did that (about five years ago, oh my) 
>>>>>> and ends with the release manager tallying the vote
>>>>>> https://lists.apache.org/thread.html/eda7e0173b247acd1dcac75dac1
>>>>>> 1f1
>>>>>> 3ca7d5bc3627bba80048a0574d@1349840288@%3Cdev.lucenenet.apache.or
>>>>>> g%3E
>>>>>>
>>>>>> One of the more involved examples is 
>>>>>> http://commons.apache.org/releases/prepare.html#Voting_On_Releas
>>>>>> e - Commons also has a nice list of things to check for a 
>>>>>> releaae and an extra page of all the things that need to be done 
>>>>>> once the vote has passed.
>>>>>>
>>>>>> So you need to call for a vote here and 72 hours later you can
>>> publish
>>>>>> the release (assuming we muster three +1s, which I'd expect). 
>>>>>> Given you are now a PMC member yourself you should have all the 
>>>>>> karma required to perform the next steps (or we can arrange to 
>>>>>> grant it to
>>>>> you).
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> PS: the ASF doesn't care whether we call the release ALPHA, 
>>>>>> beta, preview or yellow. If the intended audience is the general 
>>>>>> public and not the folks subscribing to the dev list, it is a 
>>>>>> release that has
>>> to
>>>>>> follow the process.
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> linkedin: http://www.linkedin.com/in/lazaroflima
>>> - Tornar o simples complicado é fácil, tornar o complicado simples é 
>>> criatividade, vontade e conhecimento! -
>>>

Reply via email to