7 ms·

Common Lisp ASDF maintainer considers resignation

147 points by clircle 5y ago

reikonomusha 5y ago
A new maintainer was added to the software in question who is slightly less conservative about making changes, and the problematic PR has been merged. There's no real news; just a couple frustrated people who needed to vent.
jmercouris 5y ago
Well see what happens. I’m sure it’ll be fine in the end.
- phoe-krk 5y ago
  The "I'm sure it'll be fine in the end" tends to happen because people often do invisible but crucial work in hope to make it fine in the end.
tgbugs 5y ago
For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38 https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
- ozten 5y ago
  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 that is a burden for us as ASDF maintainers, and we want to clean up our code and stop supporting it altogether."
  - tgbugs 5y ago
    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.
    - remexre 5y ago
      Well, I have to manually update SBCL's ASDF because otherwise package-local-nicknames aren't supported by uiop:define-package, and the new-uiop-loading needs to be done before my systems load for package-inferred-system to not choke...
    - d3nj4l 5y ago
      So another Python 2 vs 3 situation?
      - kjs3 5y ago
        Seems somewhat less impactful than that, but analogous, yes.
      - tgbugs 5y ago
        Not quite. The analogy is present explicitly in the gist but the comparison isn't particularly useful for understanding the social dynamics of the situation here.
      - guenthert 5y ago
        Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.
      - im3w1l 5y ago
        This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was a chicken and egg issue.
- fault1 5y ago
  direct link to the tl;dr part: https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38#tldr https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
- Others 5y ago
  Is it really sane to have a world of software that can’t survive new compiler or loader warnings? That just seems crazy to me
  - dathinab 5y ago
    > That just seems crazy to me its crazy, and supper harmful sadly it's not that rare in e.g. C/C++ as far as I know
  - jbovlaste 5y ago
    Breaking over new warnings seems crazy, but that can be one of the prices of stability. C, Perl, JavaScript and others have similar problems and come to their own solutions. (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.
  - tgbugs 5y ago
    There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.
    - thayne 5y ago
      Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?
    - jevoten 5y ago
      Running a red light is dangerous, therefore let's remove red lights..
- throwaway81523 5y ago
  Thanks for that link. It is an overlong but has some interesting comments about Lisp culture, Hyrum's law, and backwards compatibility. "Don't break stuff" is valuable.
deleted 5y ago
[deleted]
d3nj4l 5y ago
To people as lost about this as I was: ASDF here is the common lisp build system [1], not the tooling version manager [2]. Entirely my fault I was confused, tbh. 1: https://asdf.common-lisp.dev https://asdf.common-lisp.dev 2: https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
- opan 5y ago
  I thought maybe it was like BDFL but different words.
CoastalCoder 5y ago
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.
- nielsbot 5y ago
  I like that the language is also minimally-dramatic. Seems like the product of a clear-minded thinker. (And/or many revisions).
- reikonomusha 5y ago
  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 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.
  - robertlagrant 5y ago
    You're inventing things like "judging and chastising" - they do not appear to be present in the original text. Mischaracterisation is a bad idea.
akkartik 5y ago
Two obvious constraints in sharing software: * If software producers are pushing out obviously incompatible changes (excluding Hyrum's law and https://xkcd.com/1172 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 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.
- EuAndreh 5y ago
  > If software consumers can't handle new warnings, the eco-system is broken. This includes C (...) 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?
  - eropple 5y ago
    A frothy discussion along these lines is a big part of why we have -Wextra.
- patrickmay 5y ago
  I don't think it's reasonable to exclude Hyrum's law in this case. The existing users of ASDF aren't doing anything prohibited by the software. The new change being pushed by the ASDF maintainers breaks existing builds and will break more when they promote it from a warning to an error, as planned. "Don't break userspace" is a solid guideline. The ASDF maintainers should come up with a less opinionated way to achieve their goals.
  - akkartik 5y ago
ouphe 5y ago
valyagolev 5y ago
the discussion of "gifts" etc in https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38 https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3... (which is a great suggestion to read to understand what's up with ASDF) reminds of the bigger context – the ongoing "discussion" about the "responsibilities" of open source developers. i'm putting both words into quotes because it doesn't seem that the language we have even supports discussing that there's any responsibility Antoine de Saint-Exupéry's weird saying comes to mind, though. “You become responsible for what you've tamed.”
- Jach 5y ago
  "It is the time you have wasted for your rose that makes your rose so important." "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.
eslaught 5y ago
People here should also review the follow-up post: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-January/006681.html 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.
- reikonomusha 5y ago
  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.
  - brabel 5y ago
    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?
drekipus 5y ago
If someone gives you a PR that is a small, minimal change, and is backwards compatible, but fixing a load of issues because someone wants to improve their system and is often being used in tandem with yours... then you're kinda just being a troll. 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.
- reikonomusha 5y ago
  On the other hand, if a single, foundational project is continually issuing PRs across the ecosystem that, at the end of the day, are not a result of changes that seem to benefit the user tangibly, then I could see it getting annoying for project maintainers.
  - Arcsech 5y ago
    “Continually” is a pretty strong word for one change.
    - reikonomusha 5y ago
      What's not obvious from the discussion here and elsewhere is that this was not the only change coming from ASDF to this same maintainer. The maintainer in question is also an SBCL developer, who is responsible for upgrading and shipping copies of ASDF with that implementation of Lisp. So it wasn't his first rodeo dealing with ASDF changing behavior (and, sometimes, breaking his users' code downstream). Finally, this wasn't one change to one project; this was one flavor of change that was being sent to the whole "edicl" collection of projects.
aidenn0 5y ago
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"
- reikonomusha 5y ago
  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.
- BeetleB 5y ago
  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.

147 points by clircle 5y ago

A new maintainer was added to the software in question who is slightly less conservative about making changes, and the problematic PR has been merged. There's no real news; just a couple frustrated people who needed to vent.

jmercouris 5y ago

Well see what happens. I’m sure it’ll be fine in the end.

phoe-krk 5y ago
The "I'm sure it'll be fine in the end" tends to happen because people often do invisible but crucial work in hope to make it fine in the end.

tgbugs 5y ago

For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38 https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...

ozten 5y ago
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 that is a burden for us as ASDF maintainers, and we want to clean up our code and stop supporting it altogether."
- tgbugs 5y ago
  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.
  - remexre 5y ago
    Well, I have to manually update SBCL's ASDF because otherwise package-local-nicknames aren't supported by uiop:define-package, and the new-uiop-loading needs to be done before my systems load for package-inferred-system to not choke...
  - d3nj4l 5y ago
    So another Python 2 vs 3 situation?
    - kjs3 5y ago
      Seems somewhat less impactful than that, but analogous, yes.
    - tgbugs 5y ago
      Not quite. The analogy is present explicitly in the gist but the comparison isn't particularly useful for understanding the social dynamics of the situation here.
    - guenthert 5y ago
      Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.
    - im3w1l 5y ago
      This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was a chicken and egg issue.
fault1 5y ago
direct link to the tl;dr part: https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38#tldr https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
Others 5y ago
Is it really sane to have a world of software that can’t survive new compiler or loader warnings? That just seems crazy to me
- dathinab 5y ago
  > That just seems crazy to me its crazy, and supper harmful sadly it's not that rare in e.g. C/C++ as far as I know
- jbovlaste 5y ago
  Breaking over new warnings seems crazy, but that can be one of the prices of stability. C, Perl, JavaScript and others have similar problems and come to their own solutions. (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.
- tgbugs 5y ago
  There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.
  - thayne 5y ago
    Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?
  - jevoten 5y ago
    Running a red light is dangerous, therefore let's remove red lights..
throwaway81523 5y ago
Thanks for that link. It is an overlong but has some interesting comments about Lisp culture, Hyrum's law, and backwards compatibility. "Don't break stuff" is valuable.

deleted 5y ago

[deleted]

d3nj4l 5y ago

To people as lost about this as I was: ASDF here is the common lisp build system [1], not the tooling version manager [2]. Entirely my fault I was confused, tbh. 1: https://asdf.common-lisp.dev https://asdf.common-lisp.dev 2: https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf

opan 5y ago
I thought maybe it was like BDFL but different words.

CoastalCoder 5y ago

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.

nielsbot 5y ago
I like that the language is also minimally-dramatic. Seems like the product of a clear-minded thinker. (And/or many revisions).
reikonomusha 5y ago
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 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.
- robertlagrant 5y ago
  You're inventing things like "judging and chastising" - they do not appear to be present in the original text. Mischaracterisation is a bad idea.

akkartik 5y ago

Two obvious constraints in sharing software: * If software producers are pushing out obviously incompatible changes (excluding Hyrum's law and https://xkcd.com/1172 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 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.

EuAndreh 5y ago
> If software consumers can't handle new warnings, the eco-system is broken. This includes C (...) 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?
- eropple 5y ago
  A frothy discussion along these lines is a big part of why we have -Wextra.
patrickmay 5y ago
I don't think it's reasonable to exclude Hyrum's law in this case. The existing users of ASDF aren't doing anything prohibited by the software. The new change being pushed by the ASDF maintainers breaks existing builds and will break more when they promote it from a warning to an error, as planned. "Don't break userspace" is a solid guideline. The ASDF maintainers should come up with a less opinionated way to achieve their goals.
- akkartik 5y ago

ouphe 5y ago

valyagolev 5y ago

the discussion of "gifts" etc in https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef38 https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3... (which is a great suggestion to read to understand what's up with ASDF) reminds of the bigger context – the ongoing "discussion" about the "responsibilities" of open source developers. i'm putting both words into quotes because it doesn't seem that the language we have even supports discussing that there's any responsibility Antoine de Saint-Exupéry's weird saying comes to mind, though. “You become responsible for what you've tamed.”

Jach 5y ago
"It is the time you have wasted for your rose that makes your rose so important." "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.

eslaught 5y ago

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

reikonomusha 5y ago
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.
- brabel 5y ago
  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?

drekipus 5y ago

If someone gives you a PR that is a small, minimal change, and is backwards compatible, but fixing a load of issues because someone wants to improve their system and is often being used in tandem with yours... then you're kinda just being a troll. 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.

reikonomusha 5y ago
On the other hand, if a single, foundational project is continually issuing PRs across the ecosystem that, at the end of the day, are not a result of changes that seem to benefit the user tangibly, then I could see it getting annoying for project maintainers.
- Arcsech 5y ago
  “Continually” is a pretty strong word for one change.
  - reikonomusha 5y ago
    What's not obvious from the discussion here and elsewhere is that this was not the only change coming from ASDF to this same maintainer. The maintainer in question is also an SBCL developer, who is responsible for upgrading and shipping copies of ASDF with that implementation of Lisp. So it wasn't his first rodeo dealing with ASDF changing behavior (and, sometimes, breaking his users' code downstream). Finally, this wasn't one change to one project; this was one flavor of change that was being sent to the whole "edicl" collection of projects.

aidenn0 5y ago

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"

reikonomusha 5y ago
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.
BeetleB 5y ago
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.