Common Lisp ASDF maintainer considers resignation
mailman.common-lisp.net
mailman.common-lisp.net
"Dev: Oh, you must have been using undocumented behavior of ASDF. Your code will continue to work as before, but if you change this #\- to a #\/ it'll stop complaining. User: Our code used to work in ASDF-stable. Any warning at all breaks our build, so it's broken in ASDF-devel. Just make it work like it did in ASDF-stable again. ... User: That undocumented behavior works well for us, though. Dev: That behavior that is a burden for us as ASDF maintainers, and we want to clean up our code and stop supporting it altogether."
ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.
I know of at least one distro that forcibly upgrades the ASDF that SBCL ships, though.
I run my tests against daily upstreams because I want to know something will break before my users find it out.
That's the whole point of warnings in the first place - they're a way to communicate that people might be doing something wrong, without hard failing their builds. Otherwise what would be the difference between a warning and an error?
Likewise, opting in to warnings as failures in your build system is a perfectly reasonable decision if you want to be strict about quality, and catch potential issues early. But the fix for a warning you don't want to treat as a warning is to just suppress it somehow (or fix it anyway if it isn't a complete false positive), not demand the maintainer remove it.
(Note I'm just replying to the context of your TLDR, not the whole situation, which I haven't read through yet.)
The full story is that there is a sub class of warnings called style warnings. Any warning that is not a style warning is typically called a "full" warning. Full warnings do break compilation by default (the spec even mandates this). Style warnings do not. That is why ASDF typically starts the deprecation process with style warnings.
However, the bad system name warnings do not happen during compilation. It roughly happens during configuration time (as ASDF is building its plan). Since this is not compilation, neither the spec nor QL care about the specific types of warnings produced. That's why the bad system name warning is a "full" warning.
(For instance, C has warnings under the -W flags and you could enable them all at compile time with -Wall, but then people depended on the specific flags under that option so there's also -Wextra now.)
Stability means sometimes you stay still when there are good reasons to move, though there's always a balance. Perhaps a larger solution is needed (more prevalent version pinning, or an ASDF 4.0), but this may be a tempest in a teapot. We'll see how this particular issue shakes out.
its crazy, and supper harmful
sadly it's not that rare in e.g. C/C++ as far as I know
This part is especially relevant to some of the discussion in this thread:
> I understand that confronting this issue is more difficult than talking about whether or not ASDF should be issuing a warning. But that's not the question that is at hand.
X is a critical, core library.
Y is a very popular project.
X and Y are both open source projects with permissive licenses.
Y depends on X.
As a convenience to X itself, X makes a change that causes warnings in dependent projects (basically every project in existence). To fix the warnings, dependent projects must rename their sub-project identifiers. For Y, this means the `Y-module` identifier must change to `Y/module`. (Alternatively, you can keep `Y-module`, but you have to split apart and slightly restructure your build system files.)
Y does not want to do that because Y's project has been working fine for a decade. The change does not benefit Y. As a user of X, Y would prefer to keep the systems named as is.
X does it for them anyway and makes a PR.
Y rejects the PR. Y does not want this change. Y even believes that X should be motivated to stay backwards compatible because a popular project like Y doesn't want to change.
X writes a post smearing Y. X also lambasts the Common Lisp community at large for not jumping in to support X's call for changing Y.
I absolutely fail to see how the Common Lisp community is complicit in anything wrong... or anything at all, for that matter.
I don't feel like I'm a poor community citizen because I don't get in the middle of my neighbor's disputes with the water company we both use.
Jumping to conclusions is a favourite past-time.
In this case, Y actually affects a lot of members of the community, but I guess most couldn't be bothered to express their opinions. I don't know if the proposed change has strong enough motivation to break backwards compatibility in a language that values backwards compatibility extremely highly (or am I jumping to conclusions too?). But feels like, on the surface, the change is cosmetic and hence uncalled for?
X no longer wants to support this use-case, because they discovered that by not supporting it, they can clean up X's code a bit, and it makes X more efficient at certain tasks.
So X turned this into a warning, and is waiting for downstream projects to fix their (new) warnings, before axing this feature. But one popular project, Y, refused to make the change which clears the warning (possibly hoping that X will be more careful to support, not break, idiomatic uses of X).
In the end, project Y voluntarily and without friction added a maintainer who would be willing to keep up with these changes (which were considered by Y to be frivolous). Eventually the system was renamed.
- The switch operator is on a bathroom break
- The trolley is headed for a dead-end where it will crash and cause $100k in damages.
- Pushing the button will divert the trolley to an empty track where it will safely halt, doing no damage.
- A bystander who is not employed by the trolley company happens to observe all of this
For more people than I would have previously expected believe that the bystander has little-to-no moral obligation to push the button (and a frighteningly large number persist even when you change the scenario to the trolley hitting someone) . Someone who does push the button has gone above and beyond, as pushing the button wasn't their job after all.
I have seen a lesser version of this in some of the discussion over the past few days; plenty of commenters basically saying that it's not the job of people not involved in ASDF to lift a single finger to help the ASDF maintainers, and that it is fundamentally impossible for someone to be wrong to ever refuse to merge a patch.
I suppose if we continue this analogy the argument that Stas is making is roughly "I've had to push this button like 3 times now, this is getting ridiculous, maybe if I let it crash this one time, the trolley company will stop sending trains down this track"
On the whole though, making a comparison to trolleys crashing or $100k being wasted is a poor analogy.
So there's no uncertainty, we are talking about a project maintainer refusing to remove a warning that he thinks shouldn't have been there in the first place. It's not like there's in-fighting on the same project. It's that one independent project can't convince another independent project to make a change materially inconsequential to either.
There are plenty[1] of people who will normally do something in a situation, but will utterly refuse to if they feel someone else is trying to morally obligate them into doing it.
Wise people know to avoid using those words when they want to convince someone to do something. Appealing to morality is often a good way to polarize people. It tends to work only if the parties come from a fairly common value system.
[1] Actually, I'd wager almost everyone is like this for something - that thing varying from person to person.
Antoine de Saint-Exupéry's weird saying comes to mind, though. “You become responsible for what you've tamed.”
"It is the time I have wasted for my rose--" said the little prince, so that he would be sure to remember.
"Men have forgotten this truth," said the fox. "But you must not forget it. You become responsible, forever, for what you have tamed. You are responsible for your rose..."
"I am responsible for my rose," the little prince repeated, so that he would be sure to remember.
Then the little prince remembered something else, repeated far and wide and IN ALL CAPS so that all would see and remember, and he said to the fox, "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
--
But yeah, it's an ongoing discussion in the broader FOSS world. There aren't any central thought leaders anymore either, it's a very distributed discussion. As far as I recall reading anything of responsibility in, say, GNU's guiding philosophy, the only responsibility to users is to not force them into proprietary software and avoid pointing in that direction for solutions. Development and maintenance is typically voluntary, which naturally limits other responsibilities (Petit Prince notwithstanding), though it can also be supported by external "gifts" (their word for money). These days a lot of people only care about legal responsibility, and it can be a shock to some when they discover either as a user or an author/maintainer how little that is. I harbor a feeling that the newer generation of devs has come up without thinking much on why open source at all, it's just so common and a default in many cases. The prior gens, even if they disagreed with e.g. the GPL's viral nature, typically at least knew about and broadly agreed with GNU's 4 freedoms as one possible reason for doing FOSS in the first place. Though I think these thoughts are getting further off topic from the specific instance at play here, which in any case is full of older gen devs.
I wonder how much time it usually takes people to write those. For me, it takes a lot of time and revisions.
Likely as a result of his frustration, he is casting part of the blame for his troubles on a entire community of programmers who had absolutely nothing to do with his personal quarrel, because said programmers didn't come out of the woodwork to assist him in his goals. (The only way they could assist anyway is by pitchforks or dog-piles, which are hardly appropriate anyway.)
I felt that the maintainer of a fundamental piece of Lisp infrastructure judging and chastising an entire community of uninvolved people was completely inappropriate, and it was airing out dirty laundry to the wrong audience.
If he instead said something like:
> I have been working hard to push this critical piece of infrastructure forward, but it has been especially difficult with certain downstream maintainers of popular projects who refuse to upgrade, like So-And-So. As a community, this piece of software infrastructure is only valuable if we all upgrade. I don't have the energy or desire to repeatedly argue my case with all downstream users, and as such, I feel it might be time for me to step down from this project as maintainer.
then it would be completely appropriate and well-received. But instead he wrote something divisive and almost paternalistic.
> What is even worse is that the CL community tacitly accepts [the behavior of the person I am arguing with] as normal behavior.
This is making a judgment about what behavior "the CL community" accepts. (Unless you believe "tacit" includes anybody in the world who doesn't participate, in which case it's a vacuous statement.)
Let me quote the text for what I consider "chastising" (in the sense of "rebuking"):
> [In light of the tacit acceptance of said behavior,] I would like to see the CL open source community pause and consider what constitutes a healthy community.
He believes the community had not acted properly or communally, and would like everybody to stop and think about that, almost as a parent might admonish a child for his or her behavior.
This is in no-one's dictionary "chastising" (random dictionary plucked from search):
> chastising (Entry 1 of 2) inflicting, involving, or serving as punishment
As for "judging" - this seems proportionate. E.g. while I think your judgment is poor when you use these words, I don't think a valid criticism of your comment is that you are "judging" anything. By this definition, almost everything anyone says is "judging".
> chas·tise
> /ˈCHasˌtīz,ˌCHaˈstīz/
> verb
> rebuke or reprimand severely.
> "he chastised his colleagues for their laziness"
I disagree with what you said about "judging" as it pertains to how you interpret what I said, but I don't have anything to further clarify for you.
In any case, I hope you can now agree these claims weren't inventions.
Sorry, let me clarify. I don't see message-diplomacy as a binary thing.
The phrasing in that mailing-list message is way more diplomatic than comes naturally to me in such situations. Maybe that email has room for improvement, but I still benefit greatly such examples.
* If software producers are pushing out obviously incompatible changes (excluding Hyrum's law and https://xkcd.com/1172) to consumers, the eco-system is broken. This includes SemVer-aware package managers which transparently bump up past major-version boundaries by default. (That doesn't seem to be what's happening here.)
* If software consumers can't handle new warnings, the eco-system is broken. This includes C and now Common Lisp.
Creating an eco-system that threads the needle between these constraints is an exercise for the reader. One thing that helps is minimizing the depth of dependency stack: https://news.ycombinator.com/item?id=16882140#16882555. Beyond that, producers should be free to make incompatible changes as long as consumers can pick them up on their own schedule. Anything else is absolutely bonkers.
I didn't get that. Won't this only happen to those using `-Werror` or something similar? If so, aren't they responsible for their breakage, and not the ecosystem?
"Don't break userspace" is a solid guideline. The ASDF maintainers should come up with a less opinionated way to achieve their goals.
More generally, the way I feel about Hyrum's Law is:
* The only way to guarantee you won't run afoul of Hyrum's Law is to make no updates.
* As a consequence, I don't care about Hyrum's Law. I make updates to the best of my ability, trying not to break others, but I don't/can't guarantee they won't break others.
* If my updates can break others, I can't push them to others without explicit consent. Others have to pick them up on their own schedule, when they have the time to test them for their own context.
* If my updates can break others, others may have to make changes to them for themselves.
Rather surprisingly, these baby steps lead to a world entirely different from the one I live in. One where we don't have interchangeable parts (https://en.wikipedia.org/wiki/Interchangeable_parts) yet, where software is often tweaked for a specific situation.
I've been ranting about this for a long time: http://akkartik.name/post/division-of-labor. It's shockingly unconventional, but I find the reasoning to be ironclad. If you can think of a refutation, I'd love to hear it. (Beyond, "no way anyone will use it." My goal is to understand what we _should_ do today, excluding tech breakthroughs.)
The one open question with this approach is how to notify people when you discover a security vulnerability in the software they're running. The way we deal with such notifications today feels highly inefficient, and yet I don't really know how to improve things.
Anything being used by other people will of course have changes. Software is never static unless you keep it to yourself in a locked basement.
This whole ordeal is sort of like having arguments with the wife and proving your point all the way to the divorce court, instead of just nodding, shrugging the shoulders, and getting on with life.