freebsd-ports VS SIG-rules-authors

Agreed.

I don't think the PR reviewer is calling the author in the example, and provided useful info, pointing out the relevant example.

Also, the author notes:

> The very first comment in the thread from a reviewer was simply only one word: “Why?” - That’s it, just one word. Why did I do this? Why work with such old hardware? Why is the sky blue? How the hell am I to know the context of what they’re referring to when asking a one-worded question?

Its clear from https://github.com/freebsd/freebsd-ports/pull/189#discussion... that the author is asking why is this line needed, something a PR author should always be able to justify.

From https://github.com/freebsd/freebsd-ports/blob/main/UPDATING:

KDE: Update KDE Plasma Desktop to 5.26 · freebsd/freebsd-ports@d06d26f | https://cgit.freebsd.org/ports/commit/?id=d06d26f8c45e468021b1ec1def42fb1ce600a3dc

Say you really want to pin to Apache 2.5.54. Create a new empty repo, add a www/apache24 dir, and copy the files from that version of the ports tree into it.

They have not been stable

https://github.com/freebsd/freebsd-ports/commit/a43ec88422ee...

As for announcements: how would this information be delivered to you? :) Major breakages that impact users are expected to tracked in Ports (not pkgs) through review of /usr/ports/CHANGES and /usr/ports/UPDATING. If a port gets renamed (moved), you'll find it mentioned there, or possibly in /usr/ports/MOVED (not human-readable). You can view those on the GitHub mirror if you wish, since not everyone builds from Ports: https://github.com/freebsd/freebsd-ports

at https://github.com/freebsd/freebsd-ports/tree/main/chinese/chinese-calendar (for the port to FreeBSD) the files and Makefile are not too complex.

In this case, it seems that GitHub was asked about it. From the thread linked in the article:

> After a fruitful exchange with GitHub support staff, I was able to confirm the following (quoting with their permission):

>> I checked with our team and they confirmed that we can expect the checksums for repository release archives, found at /archive/refs/tags/$tag, to be stable going forward. That cannot be said, however, for repository code download archives found at archive/v6.0.4.

>> It's totally understandable that users have come to expect a stable and consistent checksum value for these archives, which would be the case most of the time. However, it is not meant to be reliable or a way to distribute software releases and nothing in the software stack is made to try to produce consistent archives. This is no different from creating a tarball locally and trying verify it with the hash of the tarball someone created on their own machine.

>> If you had only a tag with no associated release, you should still expect to have a consistent checksum for the archives at /archive/refs/tags/$tag.

> In summary: It is safe to reference archives of any kind via the /refs/tags endpoint, everything else enjoys no guarantees.

(posted 4 Feb 2022)

https://github.com/bazel-contrib/SIG-rules-authors/issues/11...

There's even a million linked PRs and issues where people went around and specifically updated their code to point to the URLs that were, nominally, stable.

I suspect that the GH employee who made these comments just misunderstood how these archives were being generated, or the behavior was depending on some internal implementation detail that got wiped away at some point. But if an employee at a big-ass company publicly says "yeah that's supported" to employees at another big-ass company, people are gonna take it as somewhat official.

FWIW according to https://github.com/bazel-contrib/SIG-rules-authors/issues/11... a commitment was made, although in an exchange in some support ticket, and not in documentation.