On Sun, 8 Nov 2015 09:51:07 -0800 "Dennis E. Hamilton" <orc...@apache.org> wrote:
> There is interesting discussion on this thread that devolves into what > compression to use as the single source-package case. My reaction is that most (all?) linux/non-windows builders will be happy with the proposed .bz2 compression. However I fear that Windows builders may think only in terms of 7zip (or zip as being compression of choice). For them we ought make available a package that opens in the default Windows Archive Manager, whatever that is. > > I do not support this proposal as a first-choice alternative to what may be a > surmountable problem. > > I want to speak to some higher-level issues, below. > > MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a > source release, using an SVN working copy of the released branch and version. > One produced on Windows for Windows should not present the interoperability > and interchange problems that other arrangements introduce. Unzip onto > non-Windows platforms should also work properly. These things are relatively > easy to check and confirm for a power user such as myself, despite my not > being a core developer of the code itself. I will also document the > procedure so that anyone can replicate it. > > It should be easy for other committers to unpack the zip and confirm its > reliability and accuracy on Windows and other platforms. They could even add > their counter-signing digital signatures. > > If that fails, then it would be time for a Plan B. (A possible unexpected > difficulty may have to do with line ends on text files across platforms, > depending on whether tools address that as well as SVN clients do.) > > - Dennis > > - - - - - - - - - - - - > > The TL;DR: > > I am going to appeal to the Apache Project Maturity Model because I believe > it is applicable here, whatever the status of the document at > <http://community.apache.org/apache-way/apache-project-maturity-model.html>. > > I think the relevant considerations of what should be *strived*for* are > > CD10: The project produces Open Source software, for distribution to the > public at no charge. > > CD20: The project's code is easily discoverable and publicly accessible. > > CD30: The code can be built in a reproducible way using widely available > standard tools. > > RE10: Releases consist of source code, distributed using standard and open > archive formats that are expected to stay readable in the long term. > > Something that is not in this list, but I see as a corollary, is that how we > do these things is part of demonstrating care for the downstream users of the > software we produce, for whatever reason they want to consult, examine, learn > from, or even develop with, and whenever they choose to do so with a given > source release. > > - - - - - - - - - - - > > MY QUESTION: There should never be a permissions issue in unpacking a Zip > file on Windows. The only barriers are (1) file names must be ones that are > acceptable and unique when extracted into an NTFS file system and (2) empty > directories are not created, even if loaded into later in the stream, and > there is no use of Zip extensions that apply only to Unix systems and Unix > permissions. There are also concerns about length of full-path file names. > (Note that some of these apply to using SVN on Windows too.) > My question is, on what platform were the troublesome Zips produced, using > what tools? We may be seeing an interchange/interoperability problem that > comes from inter-platform incompatibilities. > > MY CONCERN: These provisions are not just for project developers, but for the > public. I don't think only distributing a .tar.bz2 is very adequate with > respect to CD20. RE10 is presumably satisfied if there are no uses of > patented technologies, and assuming that no deviations from basic .tar > formatting are employed (e.g., no launching of shell scripts involved). > > I note also that Zip format is considered standard and open enough that it is > the format employed for the ODF packages used by OpenOffice and also the > packaging of .oxt extensions. It is also the packaging format of choice for > OOXML, EPUB, and other domain-specific usages, including distribution of some > libraries used in AOO and other projects. (I also notice that sometimes > those Zips of libraries don't unpack properly on Windows, but rezipping them > on Windows then works everywhere.) > > The convention has been to use Zip for Windows oriented access to the source > and some flavor of .tar.* for the Unix-oriented world. The basic use of Zip > for Windows tends to unzip easily on any platform that can deal with the > filename and folder hierarchies. > > Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know > whether it will unpack a .tar.bz2. Expecting a member of the public who > operates on Windows to know how to unpack a .tar.* is an unnecessary source > of friction. I notice that 7z does handle .rar and .msi and perhaps tar.* > compressions but I haven't checked those. > > > > - - - - - - - - - - - - - > > > -----Original Message----- > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > Sent: Saturday, November 7, 2015 15:08 > > To: dev@openoffice.apache.org > > Subject: [PROPOSAL] Distribute only one source package > > > > We currently distribute 3 source packages at > > https://archive.apache.org/dist/openoffice/4.1.2/source/ > > 1) A .tar.bz2 file (209 MBytes) > > 2) A .tar.gz file (276 Mbytes) > > 3) A ZIP file (323 MBytes) > > > > The packages are equivalent, so any one would suffice. > > > > As discussed by Regina and Juergen recently, we ship #3 as a convenience > > for Windows users but this leads to broken file permissions, so the > > recommendation for Windows users is to use #1 or #2, which makes #3 > > useless. > > > > I suggest, subject to lazy consensus, that we only distribute #1, i.e., > > the .tar.bz2 file. > > > > Reasons: > > * If we distribute one source package, it will be clear that we are all > > testing and approving the same one > > * .tar.bz2 offer better compression than .tar.gz > > * bzip2 is ubiquitous today, so I don't believe that there are systems > > capable of building OpenOffice which don't have bzip2 available > > * better compression formats exist, but they are not as widely supported > > as the three we are using now, so I'd stick with bzip2 > > > > This of course doesn't apply to 4.1.2, which is already released and > > will remain available in all three formats. > > > > Regards, > > Andrea. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- Rory O'Farrell <ofarr...@iol.ie> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
