Live data from Hacker News

Common Lisp ASDF maintainer considers resignation

mailman.common-lisp.net

61–69 of 69 posts

Re: Common Lisp ASDF maintainer considers resignation

#61

Two obvious constraints in sharing software: * 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,…

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.

Re: Common Lisp ASDF maintainer considers resignation

#62

the discussion of "gifts" etc in 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 responsibil…

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

Re: Common Lisp ASDF maintainer considers resignation

#63

Two obvious constraints in sharing software: * 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,…

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…

No opinion on what anyone should do here. It's pretty clear it's a challenging situation.

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.

Re: Common Lisp ASDF maintainer considers resignation

#64

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…

> The language is not diplomatic, in my opinion, since there doesn't appear to be any attempt at diplomacy.

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.

Re: Common Lisp ASDF maintainer considers resignation

#65
post #8
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…

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. 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 err…

The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.

Re: Common Lisp ASDF maintainer considers resignation

#66
post #6

Earlier quoted context omitted.

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.

But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.

Quicklisp doesn't include projects that build with warnings, so CL programmers are strongly incentivized to treat warnings as errors.

Re: Common Lisp ASDF maintainer considers resignation

#67
post #8

Earlier quoted context omitted.

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. 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 err…

The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.

This is very misleading. Exhibit A: the warnings in question have been present for 5 years and the projects that end up triggering the warnings have not been removed. I don't know when QL started building with an ASDF version that produced the warning, but the absolute latest would have been Feb, 2021.

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.

Re: Common Lisp ASDF maintainer considers resignation

#68

Earlier quoted context omitted.

But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.

Quicklisp doesn't include projects that build with warnings, so CL programmers are strongly incentivized to treat warnings as errors.

This is very misleading. See my other comment for more details: https://news.ycombinator.com/item?id=30052405

Re: Common Lisp ASDF maintainer considers resignation

#69
post #8

Earlier quoted context omitted.

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. 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 err…

The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.

That seems like a counterproductive decision on the part of Quicklisp. There's a reason that a distinction between warnings and errors exists, and making that decision across an entire package repository seems like a mistake to me.
Post reply on HN