On 4/3/2022 06:37, Maciej W. Rozycki wrote: > On Sun, 3 Apr 2022, Andrew Holmes wrote: > >> MIPS64 has essentially been broken/unusable for 8 kernel releases, >> including two LTS kernels, since the original commit landed. Should >> there not have been CI/tests that caught this? It's pretty major! > > AFAIK the MIPS port is only maintained on the best effort basis nowadays > I'm afraid. I.e. it's enthusiasts investing their free time for the joy > of fiddling with things. So things are bound to break from time to time > and remain unnoticed for a while. We're doing our best, but our resources > are limited. > > Taking these limitations into account I think Thomas has been doing a > tremendous job maintaining the MIPS port, but he hasn't been cc-ed on the > submission of the original change and it's very easy to miss stuff in the > flood that has only been posted to a mailing list. > > Maciej > FWIW, hot off the presses is RFC9225: https://datatracker.ietf.org/doc/html/rfc9225 4. Best Current Practises 1. Authors MUST NOT implement bugs. 2. If bugs are introduced in code, they MUST be clearly documented. 3. When implementing specifications that are broken by design, it is RECOMMENDED to aggregate multiple smaller bugs into one larger bug. This will be easier to document: rather than having a lot of hard-to-track inconsequential bugs, there will be only a few easy-to-recognise significant bugs. 4. The aphorism "It's not a bug, it's a feature" is considered rude. 5. Assume all external input is the result of (a series of) bugs. (Especially in machine-to-machine applications such as implementations of network protocols.) 6. In fact, assume all internal inputs also are the result of bugs. -- Joshua Kinard Gentoo/MIPS kumba@xxxxxxxxxx rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
