Changing my vote to +1 (binding)
I found the reason for the failing tests on Mac and Windows ... the root cause
was the different locale and the way numeric values are encoded.
In Germany we separate the 1000s with "." and the decimal part with "," and in
the US it's the opposite way. If I enforce the locale en_US and increase the
memory, then all except one test succeed.
The one failing test is still related to this locale thing, so I guess this is
something that has to be documented and should not qualify for blocking this
release.
So I would request to add suggested settings of "SBT_OPTS" to the readme for
further releases as with the current documentation it's impossible to build.
Haven't tested the binary distributions though ... however with some help of
the community I have successfully updated my PLC4X dynamic drivers that greatly
utilize Daffodil to the maven artifacts of 2.3.0
Chris
Am 23.02.19, 17:11 schrieb "Steve Lawrence" <slawre...@apache.org>:
That's for all the response from everyone so far. We'll make sure to fix
the KEYS issue for the next release. DAFFODIL-2070 [1] was created to
track that issue, and we plan to fix it in the next release. Other
comments inline.
On 2/22/19 3:45 PM, Christofer Dutz wrote:
> Hi all,
>
> I have started verifying this release ... however this is the first time
I am validating a project I'm not directly involved in.
> So I found some things that are different than with the other projects
(Not sure if this is bad or good though)
>
> So here goes:
> 1) No KEYS file (Think this has been reported)
Ticket mentioned above, we plan to fix this for the next release.
> 2) No README and RELEASE_NOTES in the RC directory
We have a REAMDE.md in the root directory of the source release and the
convenience binaries. And we've been maintaining releases notes on our
website. For example, the release for this are at
https://daffodil.apache.org/releases/2.3.0/
Looking at a few other random incubator release candidates, I don't see
a README or RELEASE_NOTES in their directories, so maybe this isn't
required, and the readme in the source and release notes on the webpage
is sufficient?
> 3) There are sha256 and 512 files ... is it OK to have the sha256 ones? I
remember us having to remove less "save" signature files
We've recently removed md5 and sha1 for this reason. I haven't yet heard
the need to remove sha256, but I'm fine doing that if that's the right
thing to do.
> 4) Is there a reason, why the "RPM" file is "2.3.0.incubating" instead of
"2.3.0-incubating" (dot instead of a dash).
The tool we use to build RPMs is very particular about versios and
filenames RPM standards. Those standards require the dot instead of the
dash. It also requires the -1 at the end as well.
> 5) It was impossible to import the GPG Key from pgp.mit.edu or any of my
known key servers (did it manually)
I've had a lot of troubles getting keys from pgp.mit.edu, always seems
to be down for me. I have uploaded it in the past for previous releases,
so it should be up there when the server works. But I'm unable to
confirm right now--I get "service temporarily unavailable" errors.
> 6) The PGP key used to sign doesn't have a valid trust chain (but the
signatures check out and refer to an apache email address)
I haven't been able to attended any key signings or anything to get
someone to sign my key. Something on my TODO list to get done.
> Formal download, hash and signature checks: All OK (see GPG remark)
> - I was able to download all artifacts
> - All 256sha hashes are valid
> - All 512sha hashes are valid
> - The signatures in the ASC files check-out (no trust chain though)
>
> Now to the source-bundle checks:
> - Was able to unpack the zip
> - Zip name contained "incubating"
> - Archive contains: DISCLAIMER, LICENSE, NOTICE, README(.md)
> - There is no RELEASE_NOTES (Think this is required)
As mentioned above, we maintain this on our website and in the release
files. I'd prefer to not have to maintain two separate versions if
having it there is sufficient.
> - Content of the README.md:
> - I it states the user list to be: u...@daffodil.apache.org, however
I'm subscribed to us...@daffodil.apache.org
> - I think the ASF HipChat was replaced with Slack (Don't know if it's
still active)
Good catch. I've opened DAFFODIL-2073 to resolve these issues. I'd
prefer to fix these in our next release if these aren't considered
blockers. Our website does mention the correct email address.
>
> Building
> - Mac 10.14.3, SBT 1.2.8, Java Oracle 1.8.0_141-b15:
> - sbt compile (success)
> - sbt test (got out of memory errors, did a 'export
SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=2G -Xmx2G"' first to
make it run)
> [error] Failed: Total 3311, Failed 35, Errors 0, Passed 3276
> - sbt it:test (all tests passed)
>
> - Windows 10, SBT 1.2.7, Java Oracle 1.8.0_101:
> - sbt compile (success)
> - sbt test (got out of memory errors, did a 'export
SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=2G -Xmx2G"' first to
make it run)
> [error] Failed: Total 3311, Failed 35, Errors 0, Passed 3276
> - sbt it:test
> Failed: 4
These failures are very interesting. All of our tests pass in TravisCI
[3] and pass on my machine, so I'm guessing these are some sort of
environment issue. I assume you're in Germany based on the .de email? I
know we've had some issues in the past related to timezones or default
encodings, so might be related to that. It would be really helpful if
you could capture the output of sbt test and send it to dev@daffodil.a.o
or create a Jira ticket for it. We can try to determine what the issue
might be and see if they should be blockers.
> ... I'll continue testing on Sunday evening ...
>
> So far I'll vote with a
>
> +0 (binding) as I don't quite know how bad the things I found are.
>
> Chris
>
>
Thanks,
- Steve
[1] https://issues.apache.org/jira/browse/DAFFODIL-2070
[2] https://issues.apache.org/jira/browse/DAFFODIL-2073
[3] https://travis-ci.org/apache/incubator-daffodil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
