I'm not a native speaker either, French is my native language. There is a reason we split src and bin distributions: The former is required, the latter is not. Binaries tar/zip files are conveniences only, strictly speaking. Some downstream users (Linux folks) build everything from first principles, don't need or want pre-built binaries.
On Tue, Sep 5, 2023, 1:10 PM Volkan Yazıcı <vol...@yazi.ci> wrote: > Gary, I am not a native speaker, but I find your tone sarcastic. I kindly > ask you to adjust it. > > [My comments are inline.] > > On Tue, Sep 5, 2023 at 6:21 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > I should be able to unzip and build, NOT unzip and then scratch my head, > > look for other files like zips and tars... > > > There is no TAR anywhere. There is only the distribution ZIP containing > `src.zip`, binary files (JARs) and so on. If you prefer `src` in a folder > rather than a compressed file, we can make that happen. The only > downside is those who download a distribution only for the JARs will also > need to reserve disk space for sources too, hence why I put them in a > compressed file. (This convention is practiced by JDK distributions too.) > > sigh, this whole dev process is > > getting WORSE. > > > > Unless you define what is worse, I cannot address it. > > And we want to spread sources in a buch of repos, bleh. > > > I am the only one in the PMC that agrees with your points regarding > mono-repo, and, together with Piotr, I am trying to find a way forward > without breaking the repository. No decisions have been made yet. I kindly > ask you to understand that everybody is trying to help with their best > intentions. > > > > All Apache and FOSS projects I've seen just have a src zip with a > snapshot > > repo minus some files, not some byzantine structure. > > > > How is this nested zip mess HELPING users and lowering the bar to entry? > > > > I can explain this. This is what > https://dist.apache.org/repos/dist/release/logging/log4j/2.19.0 looks > like: > > apache-log4j-2.19.0-bin.tar.gz > apache-log4j-2.19.0-bin.tar.gz.asc > apache-log4j-2.19.0-bin.tar.gz.sha256 > apache-log4j-2.19.0-bin.tar.gz.sha512 > apache-log4j-2.19.0-bin.zip > apache-log4j-2.19.0-bin.zip.asc > apache-log4j-2.19.0-bin.zip.sha256 > apache-log4j-2.19.0-bin.zip.sha512 > apache-log4j-2.19.0-src.tar.gz > apache-log4j-2.19.0-src.tar.gz.asc > apache-log4j-2.19.0-src.tar.gz.sha256 > apache-log4j-2.19.0-src.tar.gz.sha512 > apache-log4j-2.19.0-src.zip > apache-log4j-2.19.0-src.zip.asc > apache-log4j-2.19.0-src.zip.sha256 > apache-log4j-2.19.0-src.zip.sha512 > > This is what `log4j-tools/0.4.0` looks like: > > apache-log4j-tools-0.4.0.zip > apache-log4j-tools-0.4.0.zip.asc > apache-log4j-tools-0.4.0.zip.sha512 > > I think the latter is more self-explanatory, compact, and contains > everything the former has. > > Why are all the ".githug" files even in the source zip file? > > > > There are no `.githug` files. There is a `.github` folder. They are of > particular importance since the reusable CI workflows are part of the > release. They are code used by other projects. They will be versioned and > used by referring to their version. > > `src.zip` contains *everything* tracked by Git that is responsible for > making that release happen. It is not a sparse checkout of the actual > repository. That said, Log4j always had it; go and download any > `apache-log4j-*-src.{zip,tar.gz}` of your liking. Hence I am not able to > understand your objection for this particular occasion. >
