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

Reply via email to