hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: [VOTE] HttpComponents Client 4.2.6 release
Date Tue, 03 Sep 2013 06:03:46 GMT
Hi Sebb,

"It is essential that the files in a source release can be matched
against those in SVN."

I think that's technically not necessary according to Apache rules;  what's
necessary is that the bits in the tar or zip be based *solely* on the svn
tag and upstream dependencies.  But you really vote not on the tag but on
the tar and zip.

"But the main issue I have is that the PNG file in the ZIP archive is
corrupt."

I think that should be fixed.  It's also worth considering that perhaps
fixing up line endings for Windows users is maybe not worth the pain in the
behind at release time that it is.  Most people use editors these days that
don't care.

Karl



On Mon, Sep 2, 2013 at 9:38 PM, sebb <sebbaz@gmail.com> wrote:

> On 2 September 2013 18:28, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Mon, 2013-09-02 at 21:59 +0530, Asankha C. Perera wrote:
> >> On 09/02/2013 06:06 PM, Oleg Kalnichevski wrote:
> >> > On Mon, 2013-09-02 at 11:53 +0100, sebb wrote:
> >> > ...
> >> >
> >> > Further httpclient/src/test/resources/suffixlist.txt has got EOL=LF in
> >> > the zip file so it disagrees with the SVN tag checkout.
> >> >
> >> > Also, the *.properties files ought to be CRLF on Windows (they are
> >> > native in SVN)
> >> > Likewise *.xsl and *.css and SPNEGO.svg
> >> > Otherwise checkouts of the tag don't agree with the Zip
> >> >
> >> > I am sorry but I have no idea what this is all about. I have no idea
> why
> >> > they should agree in the first place.
> >> I guess Sebastian's concern is that if you unzip the Zip on a Windows
> >> box, and compare the result with a checkout of the tag on the same
> >> Windows system, the line endings would be different between the two for
> >> some files. Although that maybe a minor issue, if the differences are
> >> related only to the line endings of a few files, I would not consider it
> >> a blocker to the release. Personally I consider differences in line
> >> endings as ignorable, and many IDEs or file compare tools also tend to
> >> ignore them. I guess one who would look for the source releases would
> >> prefer to get it directly via the SVN tag, and ones who download the
> >> source archive of a release would generally want to refer to the code
> >> for understanding or debugging etc - so the line endings would not be
> >> that critical - my 2c
> >
> > Asankha
> > I understand the technical bits. What I do not understand is why that
> > would matter at all, why anyone in their sane mind would want to compare
> > SVN tag with the content of ZIP archive and why on earth we need to
> > waste our collective time on stuff like that?
>
> At present we create OS-specific archives - CRLF for zip (intended for
> Windows) and LF for tar.gz (intended for Un*x).
> Given that we do so, we ought to do it properly.
>
> It is essential that the files in a source release can be matched
> against those in SVN.
> That's how provenance is established, and how the reviewer knows that
> the files are OK to release.
> SVN is assumed to contain only files with correct licences etc.
> It makes the reviewers job much easier if the line endings agree.
>
> It's also easier for Windows developers if text files are in CRLF
> format. CRLF files are awkward on Un*x systems.
>
> But the main issue I have is that the PNG file in the ZIP archive is
> corrupt.
>
>
> > Oleg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

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