Gary, you got to be kidding me! On 2023-12-08, in your response to this topic, you said.
>>> I don't want to talk privately about topics that should be public. >>> It makes it impossible for anyone else to benefit from the replies >>> (YMMV on value) and search the mailing list archive in the future. Urging me to subscribe to the developers mailing list, which I needed several iterations to complete, because the subscription info on the Xalan website is wrong, then someone else told me the next wrong subscription address, and only when I tried a 3rd variant, I succeeded. After encouraging me to write here - I even expanded my original message with additional information - *this* is your answer? You just wanted me to sign up to tell me that, chastising me publicly instead of in a private e-mail? I thought, that suggestions for a shift in Apache policy within the project, then maybe carrying it up the hierarchy into ASF, were at least debatable. Otherwise, I would not have wasted my time to sign up here and write a lengthy message, not just explaining what I do not like but also why and how to do it better ina solution-oriented way. This was the last straw. I lately contributed quite a few PRs to the Maven migration, because Joe is such a nice guy and always polite, open-minded and grateful. He cheered me up when someone else was trolling me during code reviews. Thanks for everything, Joe. Thanks for nothing to everyone else. I am out of here for good. I guess, you guys can take it from here, just like before. I will not contribute to this project any longer, even though I had quite a few topics in the pipeline. It is not about the fact that you, Gary, disagree with my suggestion here, but about the dysfunctional way you communicate with me as a human being. Bye now -- Alexander Kriegisch Gary Gregory schrieb am 22.12.2023 08:30 (GMT +07:00): > > > Alexander, > > > Releasing on downloads.apache.org > <http://downloads.apache.org> is Apache policy, period, and > not up for discussion here within the Xalan project. Please read > https://www.apache.org/legal/release-policy.html > > > Gary > > > On Thu, Dec 21, 2023, 7:45 PM Alexander Kriegisch > <alexan...@kriegisch.name <mailto:alexan...@kriegisch.name> > > wrote: > >> Gary Gregory wrote elsewhere a couple of weeks ago: >> >> >>> The source zip/tar is an Apache requirement, the binary, a >> >>> convenience. Both are "easy" to produce with a Maven build, for >> >>> example, see Apache Commons VFS (or any Apache maven multi module >> >>> project). >> >> Such requirements might exist, I just want to point out that they are >> outdated and should be abolished or even relaxed. They were no doubt >> made in a time before GitHub and Maven Central, but times have changed. >> Such distributions are anachronisms. If the requirement is that a >> complete build ought to be possible from the source ZIP, what is the >> benefit of that? Users can instead be instructed to just clone the Git >> repo and check out the release tag. Nobody who seriously wants to build >> the product would do that from a source zip, depriving himself of the >> convenience to inspect the Git commit history, switch to other branches >> or tags, try to solve a problem in a local branch, switching back to the >> original release tag for comparison etc. >> >> Of course, it would be easy to do, if that is the requirement. It would >> just zip up the whole working directory after 'mvn clean'. I was under >> the impression that the requirement was to reconstruct the structure of >> previous source archives, e.g. Xalan-J 2.7.1, which is not the same. >> That was a misunderstanding on my part. >> >> Anyway, it is a waste of resources and yields no benefit. Even if a user >> does *not* want to clone the Git repo with history etc., he can still >> just navigate to e.g. >> >> https://github.com/apache/xalan-java/tree/xalan-j_2_7_1 >> >> click the green "Code" button and select "Download ZIP" from there, >> resulting in exactly >> >> https://github.com/apache/xalan-java/archive/refs/tags/xalan-j_2_7_1.zip >> >> That is pretty much identical to the source zip for 2.7.1, only this >> version contains the actually tagged release versions, while the >> manually created source zip contains sources many of which have a >> slightly different content, meaning that either the tag is on the wrong >> version (bad) or the source zip is not really equivalent to the >> correctly tagged 2.7.1 (equally bad). Do you see, how error-prone and >> unreliable that kind of process to recreate something that already is >> under source control and then serve it from Apache hardware is? Really, >> I do not need a Maven Assembly to reproduce something that is under SCM >> control. >> >> Grace Hopper - I hope you know who she was - famously and truly said: >> >> Humans are allergic to change. >> They love to say, "We've always done it this way." >> I try to fight that. >> That's why I have a clock on my wall that runs counter-clockwise. >> >> >>> Note that this src zip/tar file is distributed on Apache hardware >> >>> from a distribution server folder which is DIFFERENT from any other >> >>> files from a Maven repository for -sources and -javadoc JAR files. >> >> Of course, it is different, because it contains a snapshot of the source >> repo for a certain release tag, while artifacts on Maven Central contain >> sources per module. The latter do not mean to be compilable projects, >> but references, e.g. to be used when displaying the source for >> dependency classes or javadocs from an IDE. But like I explained above, >> that does not justify the existence of the former, as it can be obtained >> via Git or GitHub (replace by any other future SCM platform). >> >> Some more thoughts, after I let this topic rest for a few weeks: >> >> Assuming, you have cloned the repo already, you can create a source ZIP >> in no time for any tag, current branch head or commit ID like this: >> >> $ time git archive -o xalan-j_2_7_1-src.zip xalan-j_2_7_1 >> >> real 0m0.861s >> user 0m0.015s >> sys 0m0.000s >> >> If you have not cloned the repo yet and only want a shallow clone for >> the purpose of creating just the zip for a specific commit: >> >> $ git clone --branch xalan-j_2_7_1 --depth=1 >> https://github.com/apache/xalan-java.git >> >> Then, use 'git archive' to create a ZIP and afterwards delete the >> shallow clone again to clean up. >> >> $ git --git-dir=xalan-java/.git archive -o xalan-j_2_7_1-src.zip >> xalan-j_2_7_1 >> $ rm -rf xalan-java/ >> >> There is even 'git archive --remote', but GitHub does not support it in >> favour of its own archive download URLs, like mentioned further above. >> Again, for overview: >> >> https://github.com/apache/xalan-java/archive/refs/tags/xalan-j_2_7_1.zip >> >> You see, there are plenty of ways we could instruct users how to get >> source archives, right on the distro download page. It would be easy to >> explain, most easily the GitHub URLs, because they do not even require a >> local Git installation. (But which developer does not have that?) If I >> want to build an OSS project from source, I want a full clone, not a >> shallow copy or a ZIP. >> >> Welcome to the 21st century! ;-) >> >> -- >> Alexander Kriegisch >> https://scrum-master.de >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org >> <mailto:dev-unsubscr...@xalan.apache.org> >> For additional commands, e-mail: dev-h...@xalan.apache.org >> <mailto:dev-h...@xalan.apache.org> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
