pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: [VOTE] Release Pivot 2.0.3 - Round 3
Date Wed, 05 Jun 2013 21:54:09 GMT
Roger,
I agree with you,  comparing binary artifacts is not so useful because of
course it depends on platform, tools, compression, etc. So on binary I
could suggest to check features by running/using them, open like zip files
and inspect content, etc ... but of course one of powerful things of open
source is that anyone is able to look at software from many point of view,
a great approach to make it rock solid.

Chris, note that the problems you have with different line encodings in
Win/Linux are not real problems:
our build process in really multi-platform (releases are generated in
Linux, but only because some steps need pgp signing, svn tagging, and other
small things, but all NOT related to build of sources , because all other
steps launch our usual Ant tasks).

Anyway I think that a better flow would be to discuss some details in
another mail thread (to avoid confusion in vote mail thread) and write here
a vote with some info for it. But I don't think it's important now ...

Thank you the same for your work here to try to ensure best quality on
release artifacts.

Just after the expiration of the vote I'll post final results.

And don't worry, we can repeat the vote later ...

Bye,
Sandro

On 5 June 2013 11:15, Sandro Martini <sandro.martini@gmail.com> wrote:

> > I think Sandro created the release on Linux, so likely the line endings
> > were \n and not \r\n as they would be in Windows.  Also the .jar files
> > won't be exactly the same due to timestamps, and probably subtle JDK
> > differences (such as exact minor release number, etc.).  I used WinMerge
> > on Windows with settings to ignore line-ending diffs and "diff -r" on
OSX
> > to do my comparisons, which seems to verify that the line endings in
> the sources files are \n only.
> Yes, out Release are always generated from Linux machines (or Mac OSX by
> Todd, many time ago), related scripts are Unix shell scripts since the
> beginning ... I'd like to update them to something more portable (for
> example Gradle ...) but didn't have enough time up to now, and I'm not
sure
> it worth the effort.
>

The problem with the current build process is that it is not easy to
recreate the release artifacts from source in a platform independent way
(unless I am missing something obvious).  Ideally it should be possible to
checkout the correct tag/commit and run the relevant Ant command to
generate identical release artifacts regardless of the OS, JDK version,
locale etc. A binary comparison would confirm that the proposed release
artifacts came from the correct source code with no modifications along the
way.

I'm not sure how to proceed with this vote without setting up an equivalent
build environment to perform that kind of test.  It might be something as
simple as tweaking an existing SVN or git installation to force unix line
endings on checkout or may involve a linux build VM.  Due to other
commitments, I doubt I would even be able to attempt any of that until the
weekend.

I looked into the Ant FixCRLF task (
http://ant.apache.org/manual/Tasks/fixcrlf.html) which might be able to
help sometime in the future but couldn't quickly get a working
configuration to process the source to match the proposed release source.
 There seemed to be too many variations in line endings, encodings & EOFs
to quickly tweak.

Roger - Yes, I had figured as much.  I couldn't work out how to get
BeyondCompare to ignore line endings in its folder search mode but it is
useful to know about WinMerge.  I think the compiler flags being set to
target 1.6 will ensure that classes are the same regardless of the JDK
version.

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