4 ms·

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=

by kop316 4y ago

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 https://news.ycombinator.com/item?id=32494659 > Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken versions of software and pointing to the developers for support. Which is why https://dont-ship.it/ https://dont-ship.it/ was started.

rob74 4y ago
So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?
- ddevault 4y ago
  Distributions like Manjaro should change their behavior and quit shipping unfinished patches.
  - WesolyKubeczek 4y ago
    What if the whole point is about shipping unfinished patches? But also this should mean that the buck stops with the distribution, not with the developers.
    - mannykannot 4y ago
      What is the use case for shipping unfinished patches?
      - viraptor 4y ago
        Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/development/tools/rbspy/default.nix#L25 https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch. It's a cost/benefit calculation for the maintainers.
        MartijnBraam 4y ago
        In the case of manjaro which triggered this post, it's not that manjaro is fixing things. It's manjaro trying their absolute hardest to ship new features faster than the rest, even when those features are completely broken. Like the fun example of manjaro shipping a merge request of the SMS/chat application on the PinePhone that causes a database upgrade that can't be rolled back. This code was not intended to be merged, even less shipped.
        rcxdude 4y ago
        Yeah, it's a balancing act, and it's best when the users and maintainers are on the same page: I don't like maintainers futzing about with packages to fit to arbitrary standards (debian can be quite bad here, and the general policy of 'as close to as vanilla as possible' is something I like about arch), but on the other hand it's much appreciated when packages come with fixes for bad upstream decisions (of which there are many examples), or even important features which upstream has sat on for years (see pulseaudio support for high-quality bluetooth codecs for an example which eventually led to the patch author rage-quitting the project because they strung him along for years). As a user I'm generally happiest when I get the software with the features I want without the bugs which cause me trouble, and it's situation dependent whether the packager or upstream are working against me on that. Usually the biggest source of friction is who actually winds up supporting the result: for all that distros may encourage filing bugs on their own tracker usually users wind up going to upstream for support, even if the issue is caused by the distro's patches. Some badly behaving maintainers (and it sounds like manjaro have been far too aggressive in trying to pull in new features) have I think caused a general pushback from upstream developers as they wind up with a bunch of support requests from someone else's screw-up (see for example home-assistant's attitude to anyone else distributing their software).
    - dspillett 4y ago
      > What if the whole point is about shipping unfinished patches? Then make absolutely sure your users all realise this, and that they should come to you for support not the devs (unless they themselves are devs, have read the relevant documentation, all of it, and able to offer useful help with the matter). > But also this should mean that the buck stops with the distribution, not with the developers. The clarifying points further down the article, that is the thrust. The basic rule for releasing WiP code being “don’t” and the advanced rule being “don’t, unless you really know what you are doing and can support it yourself”.
    - ddevault 4y ago
      If the point of your product is shooting yourself in the face, you should find a different point. Not all ideas are worth pursuing.
- kop316 4y ago
  > start calling themselves "nightly" distros It's not a "nightly" distro, it's a "let's take patches that are unfinished, release them into the wild onto unsuspecting users, and let the upstream developers deal with it" distro.
  - Spivak 4y ago
    Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.
    - MartijnBraam 4y ago
      It is generally not a problem, distributions are doing absolutely great things and I like working with distributions a lot more than dealing with something like flatpak. It's just that some distributions make a huge mess of it, don't want to work with developers and actively push off all the work to the developers for patches that have not even shipped, not even been merged or most painfully: not even been reviewed yet.
    - hulitu 4y ago
      > Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. Then don't do 15 different versions of your software. I ask again: Why do i need GTK1, 2, 3 and 4 on my system ? Why KDE 5 is not compatible with KDE4 ?
      - detaro 4y ago
        Versions != major releases
    - crest 4y ago
- COGlory 4y ago
  openSUSE Tumbleweed
- srmrqaz 4y ago
  I always thought that the whole point of Manjaro was to be the "more stable" Arch linux, since it holds the rolling updates and releases them at once every month. Is that not right anymore?
  - zdragnar 4y ago
    I've been using Manjaro for quite awhile and have yet to have an issue with a broken update. YMMV I guess.
    - rob74 4y ago
      Yeah, but I can understand that the experience of the users (who generally don't see any issues) is different from the experience of the application maintainers (where the few users that do see issues report those issues).
- sillystuff 4y ago
  I think this is asking that we avoid additional episodes like the Redhat gcc "2.96" issue where redhat took cvs head, and slapped a version number on it that would have been the next release and shipped it with their "stable" distribution. GCC devs got tons of complaints about their shipping a broken compiler that couldn't compile the kernel and tracked it down to redhat shipping pre-release WIP software as if it were the new release version. GCC completely skipped the 2.96 version number, so "2.96" ended up being a redhat exclusive-- the fake 2.96 would have been a recurring source of pain due to confused redhat users making bug reports to the gcc project. https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.html https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...
- deleted 4y ago
  [deleted]
- scrame 4y ago
  Is there any dev methodology that doesn't get bogged down by process?
- RunningDroid 4y ago
  > Is there any rolling release distro that already follows the suggestion of only distributing tagged releases? Void Linux

by kop316 4y ago

rob74 4y ago

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

ddevault 4y ago
Distributions like Manjaro should change their behavior and quit shipping unfinished patches.
- WesolyKubeczek 4y ago
  What if the whole point is about shipping unfinished patches? But also this should mean that the buck stops with the distribution, not with the developers.
  - mannykannot 4y ago
    What is the use case for shipping unfinished patches?
    - viraptor 4y ago
      Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/development/tools/rbspy/default.nix#L25 https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch. It's a cost/benefit calculation for the maintainers.
      - MartijnBraam 4y ago
        In the case of manjaro which triggered this post, it's not that manjaro is fixing things. It's manjaro trying their absolute hardest to ship new features faster than the rest, even when those features are completely broken. Like the fun example of manjaro shipping a merge request of the SMS/chat application on the PinePhone that causes a database upgrade that can't be rolled back. This code was not intended to be merged, even less shipped.
      - rcxdude 4y ago
        Yeah, it's a balancing act, and it's best when the users and maintainers are on the same page: I don't like maintainers futzing about with packages to fit to arbitrary standards (debian can be quite bad here, and the general policy of 'as close to as vanilla as possible' is something I like about arch), but on the other hand it's much appreciated when packages come with fixes for bad upstream decisions (of which there are many examples), or even important features which upstream has sat on for years (see pulseaudio support for high-quality bluetooth codecs for an example which eventually led to the patch author rage-quitting the project because they strung him along for years). As a user I'm generally happiest when I get the software with the features I want without the bugs which cause me trouble, and it's situation dependent whether the packager or upstream are working against me on that. Usually the biggest source of friction is who actually winds up supporting the result: for all that distros may encourage filing bugs on their own tracker usually users wind up going to upstream for support, even if the issue is caused by the distro's patches. Some badly behaving maintainers (and it sounds like manjaro have been far too aggressive in trying to pull in new features) have I think caused a general pushback from upstream developers as they wind up with a bunch of support requests from someone else's screw-up (see for example home-assistant's attitude to anyone else distributing their software).
  - dspillett 4y ago
    > What if the whole point is about shipping unfinished patches? Then make absolutely sure your users all realise this, and that they should come to you for support not the devs (unless they themselves are devs, have read the relevant documentation, all of it, and able to offer useful help with the matter). > But also this should mean that the buck stops with the distribution, not with the developers. The clarifying points further down the article, that is the thrust. The basic rule for releasing WiP code being “don’t” and the advanced rule being “don’t, unless you really know what you are doing and can support it yourself”.
  - ddevault 4y ago
    If the point of your product is shooting yourself in the face, you should find a different point. Not all ideas are worth pursuing.
kop316 4y ago
> start calling themselves "nightly" distros It's not a "nightly" distro, it's a "let's take patches that are unfinished, release them into the wild onto unsuspecting users, and let the upstream developers deal with it" distro.
- Spivak 4y ago
  Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.
  - MartijnBraam 4y ago
    It is generally not a problem, distributions are doing absolutely great things and I like working with distributions a lot more than dealing with something like flatpak. It's just that some distributions make a huge mess of it, don't want to work with developers and actively push off all the work to the developers for patches that have not even shipped, not even been merged or most painfully: not even been reviewed yet.
  - hulitu 4y ago
    > Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. Then don't do 15 different versions of your software. I ask again: Why do i need GTK1, 2, 3 and 4 on my system ? Why KDE 5 is not compatible with KDE4 ?
    - detaro 4y ago
      Versions != major releases
  - crest 4y ago
COGlory 4y ago
openSUSE Tumbleweed
srmrqaz 4y ago
I always thought that the whole point of Manjaro was to be the "more stable" Arch linux, since it holds the rolling updates and releases them at once every month. Is that not right anymore?
- zdragnar 4y ago
  I've been using Manjaro for quite awhile and have yet to have an issue with a broken update. YMMV I guess.
  - rob74 4y ago
    Yeah, but I can understand that the experience of the users (who generally don't see any issues) is different from the experience of the application maintainers (where the few users that do see issues report those issues).
sillystuff 4y ago
I think this is asking that we avoid additional episodes like the Redhat gcc "2.96" issue where redhat took cvs head, and slapped a version number on it that would have been the next release and shipped it with their "stable" distribution. GCC devs got tons of complaints about their shipping a broken compiler that couldn't compile the kernel and tracked it down to redhat shipping pre-release WIP software as if it were the new release version. GCC completely skipped the 2.96 version number, so "2.96" ended up being a redhat exclusive-- the fake 2.96 would have been a recurring source of pain due to confused redhat users making bug reports to the gcc project. https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.html https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...
deleted 4y ago
[deleted]
scrame 4y ago
Is there any dev methodology that doesn't get bogged down by process?
RunningDroid 4y ago
> Is there any rolling release distro that already follows the suggestion of only distributing tagged releases? Void Linux