[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Testing pax on platforms was Re: Using pax instead of cpio in dist.sh

From: Tobias Ringstrom <tobias_at_ringstrom.mine.nu>
Date: 2004-04-03 19:51:05 CEST

Ben Reser wrote:

>>The only reason to test pax would be to test for bugs in the one that
>>will be used to produce the official tarball. If five different pax
>>implementations and versions will be used, they should either all be
>>tested, or none of them needs to be tested. Pax produces USTAR files.
>>That is the purpose of pax. There is no reason to test the pax in RHL9
>>if you will use OS X to produce the tarballs. That was all I meant.
>>That said, I think we can trust pax to be correct, and we don't need to
>>test it. I'm not against testing it, of course. I just wanted to
>>explain why I though that it was unneccessary to test it.
>
> Given that we've now tried 3 different tar implementations looking for
> one that produces portable and correct tar archives and so far we
> haven't found one... I'm not quite as confident of this as you are.

The best thing would be to have one dedicated release build machine to
make sure that our releases are of a consistent (high) quality. So far
we've have new dist bugs with almost every release. :-(

Will you really send out new test tarballs each time you build the
release on a new machine? In case it's not possible to have a dedicated
release build machine, I was trying to suggest that the probablity of a
pax bug is low enough that we can risk a release, and if there is a pax
bug on that build machine, we can quickly release another release.
Release numbers are relatively cheap, and the probability is low.

/Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 3 19:51:24 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.