Alexander, Uh? I interact with a lot of people on a lot of mailing lists. I aim to answer each question, from _anyone_, one at a time on the proper channel for that question, which in Apache projects means a _mailing list_ (user, developer, security, PMC, or other) for that one project, for the benefit of all. Software is not the only reusable quantity, the information needs to be as well. If I replied privately to everyone who is asking for special treatment through a private message, then zero other persons benefit, and I would waste time repeating myself. I can't keep track of the history of which user wants what information from what communication channel. I get a message, I reply, if it's on the wrong channel (a private message), I redirect, and I move on. If someone replies before I do, that much the better, and I can move on to the next issue.
Cheers, Gary On Thu, Dec 21, 2023 at 9:02 PM Alexander Kriegisch <alexan...@kriegisch.name> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
