Live data from Hacker News

Common Lisp ASDF maintainer considers resignation

mailman.common-lisp.net

41–50 of 69 posts

Re: Common Lisp ASDF maintainer considers resignation

#41
Something I have noticed. Consider the following trolley problem:

- 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"

Re: Common Lisp ASDF maintainer considers resignation

#42
post #41

Something I have noticed. Consider the following trolley problem: - 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 woul…

Stas is more like, "I have pushed this button in the past for this very project, and it caused my downstream users to blame me for their software breaking, and so I don't feel compelled to continue doing so."

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.

Re: Common Lisp ASDF maintainer considers resignation

#43
post #41

Something I have noticed. Consider the following trolley problem: - 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 woul…

The key words in your comment are "moral" and "obligation". And yes, vastly differing standards on both exist.

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.

Re: Common Lisp ASDF maintainer considers resignation

#44

People here should also review the follow-up post: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-Ja... 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.

There are project X and project Y.

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.

Re: Common Lisp ASDF maintainer considers resignation

#45

People here should also review the follow-up post: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-Ja... 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.

There are project X and project Y. 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`…

It's very common that people take the behaviour of one or two people they actually interact with as the behaviour of the "community".

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?

Re: Common Lisp ASDF maintainer considers resignation

#46
post #45

Earlier quoted context omitted.

There are project X and project Y. 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`…

It's very common that people take the behaviour of one or two people they actually interact with as the behaviour of the "community". 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 l…

A long time ago, countless projects started using X in a way that wasn't documented (specifically, using X to define multiple modules in one file, instead of one module per file), and it has worked forever just fine. I consider it an unintended (and nice) feature.

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.

Re: Common Lisp ASDF maintainer considers resignation

#47
post #6
post #4

Earlier quoted context omitted.

TLDR; "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…

Another TLDR would be; ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.

You test against a devel version so that your users don't have to find out your software is broken the moment the devel is promoted to stable.

I run my tests against daily upstreams because I want to know something will break before my users find it out.

Re: Common Lisp ASDF maintainer considers resignation

#49

I learn a lot about diplomatic language from posts like that. I wonder how much time it usually takes people to write those. For me, it takes a lot of time and revisions.

The language is not diplomatic, in my opinion, since there doesn't appear to be any attempt at diplomacy. To me it reads as an over-worked individual who tried to do something he believed was good for a project he's not affiliated with, but it didn't go according to plan because that project's maintainer didn't agree with his approach, and hence feels extremely frustrated. Likely as a result of his frustration, he is…

You're inventing things like "judging and chastising" - they do not appear to be present in the original text. Mischaracterisation is a bad idea.

Re: Common Lisp ASDF maintainer considers resignation

#50

Earlier quoted context omitted.

The language is not diplomatic, in my opinion, since there doesn't appear to be any attempt at diplomacy. To me it reads as an over-worked individual who tried to do something he believed was good for a project he's not affiliated with, but it didn't go according to plan because that project's maintainer didn't agree with his approach, and hence feels extremely frustrated. Likely as a result of his frustration, he is…

You're inventing things like "judging and chastising" - they do not appear to be present in the original text. Mischaracterisation is a bad idea.

Let me quote the text for what I consider "judging" (in the sense of making a presumptuous claim about or characterization of a person or group):

> 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.

Post reply on HN