Here's a fun one: "tabled" In the US, it means "it's removed from the discussion", in the EU, it means "it's open for debate"! ;-)
Gary On Thu, Dec 21, 2023 at 10:50 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote: > > Xander, the point is that the Xalan Dev list doesn't have the authority to > drop the distro files. Telling us you think they're old-school -- and I might > be convinced to agree they're no longer the best solution -- is not very > productive. If you want to change Apache policy driven by Apache's lawyers, > you need to take that up with Apache's governing body and the lawyers. > > If you can succeed in getting that policy changed we can discuss implementing > the change. Until then, however we implement it, we have no choice but to > build distros in order to do a formal release. > > There are plusses and minuses to bring a member of the Apache family. One of > the plusses is that we do have some legal cover. One of the minuses is that > we have to jump through specific hoops until told otherwise. > > If this wasn't an Apache project, I'd say you have an excellent point. But it > is, and the motion has to be tabled as our of scope and not something we have > the resources to tackle. > > No disrespect, just the realities and a respectful "thanks for the suggestion > but that isn't currently an option for us." > > It _was_ a perfectly reasonable question to ask, and I wouldn't have > remembered the explicit policy statement myself if you hadn't asked and Gary > hadn't pointed to it. So I thank you for helping my reboot into Apache; if > the discussion had been kept private I wouldn't have learned from it. > > > > -- > /_ Joe Kesselman (he/him/his) > -/ _) My Alexa skill for New Music/New Sounds fans: > / https://www.amazon.com/dp/B09WJ3H657/ > > Caveat: Opinionated old geezer with overcompensated writer's block. May be > redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. > ________________________________ > From: Gary Gregory <garydgreg...@gmail.com> > Sent: Thursday, December 21, 2023 10:12:10 PM > To: dev@xalan.apache.org <dev@xalan.apache.org> > Subject: Re: On necessity and added value of source/binary distribution > archives > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
