System76 / Pop! OS team, not upstreaming your patches isn’t going to benefit your users

I saw a few cases of those situations happening recently

  1.  System76 / Pop! OS finds a bug (where ‘find’ often means that they confirm an existing upstream bug is impacting their OS version)
  2. They write a patch or workaround, include it in their package but don’t upstream the change/fix (or just drop a .patch labelled as workaround in a comment rather than submitting it for proper review)
  3. Later-on they start commenting on the upstream (Ubuntu, GNOME, …) bugs trackers, pointing out to users that the issue has been addressed in Pop! OS, advertising how they care about users and that’s why they got the problem solved in their OS

System76 / Pop! OS team, while you should be proud of the work you do for you users I think you are going the wrong way there. Working on fixes and including them early in your product is one thing, not upstreaming those fixes and using that for marketing you as better than your upstreams is a risky game. You might be overlooking that now, but divergence has a cost, as does not having good relationship with your upstreams.

What triggered me to write this blog today was after reading https://blog.system76.com/post/185276928258/system76-news-a-may-with-zing yesterday which included that item

Fixes

We’ve updated the youtube-dl package to a newer version. This package, maintained by Debian and Canonical, is used for downloading videos from YouTube. Changes made by Google to the YouTube API had recently broken this package in the Ubuntu repositories, hence the update.

As the description mentions, they are using the Ubuntu package (which is coming from Debian). I went to check a bit more what happened and what’s the status of the fix, and oh, surprises!
– they didn’t report the bug in launchpad
– they didn’t send their patch/fix to launchpad
– they didn’t get in touch with Ubuntu/Canonical about fixing the issue in a SRU

So instead of working with their upstream on a fix which would benefit Ubuntu and Pop! OS users they did an upload in their overlay PPA with as description
‘ * Backport to Pop!_OS because Ubuntu is too slow.’

Thanks System76 for not trying to work with us and then stab us in the back with that package description.

Ubuntu users, sorry that we didn’t get to fix that earlier since it was not brought to our attention, I did upload SRUs for Bionic and Disco now, details on https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/1831778

(Other recent examples on https://gitlab.gnome.org/GNOME/gnome-shell/issues/1084 or https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1731318/comments/6)

23 thoughts on “System76 / Pop! OS team, not upstreaming your patches isn’t going to benefit your users”

  1. youtube-dl can take care of updating itself with youtube-dl -U.

    Stuff can break regularly and it is bet to keep it up-to-date with a cron job (or systemd timer) that invoke above command once a day.

      1. OK, didn’t know. Not sure this is a good idea for a program such as youtube-dl that will inevitably break given enough time, and that needs to be regularly updated.

  2. Actually, if you had fact-checked with us before writing this, the package is not coming from Ubuntu, but from the Debian Multimedia repository. We did not write any patches, because it’s already patched upstream. There’s also a bug report about it on Launchpad.

        1. The report is from 2015 and not from system76, it doesn’t look like you commented/reached out either saying it’s an issue for you nor trying to see if there would be possible to accommodate your needs…

      1. I’m don’t use Pop!_OS (or anything else Debian‐derived) and I’m not a big fan of the Launchpad platform, but… if the issue is fixed in upstream (that is, youtube-dl itself, not Debian or Ubuntu or any layer in between the yt-dl project and Pop!), why does it need a bug in Launchpad?

    1. Wait, so if the package comes from Debian Multimedia, the package changelog makes no sense:

      > ‘ * Backport to Pop!_OS because Ubuntu is too slow.’

      Should it be instead “because Debian is too slow”?

      It would still be some entitle passive-aggressive shit, but at least it would be more accurate?

    1. On the first on your provide a patch labelled as workaround in middle of the bug report.

      On the second it tooks me to reply to your launchpad’s “Pop!OS advertisement comment saying that a patch sitting in bugzilla is not the right way to get code up for review to finally decide to create a proper merge request (which magically got you a review that you were complaining about not getting).

      Your youtube-dl coming from Debian doesn’t change the situation than you are based on Ubuntu but preferred to do your own ppa overlay solution rather than working with your direct upstream on getting the problem resolved in the right place.

  3. Knocking Ubuntu was wrong and unnecessary and will never happen again.

    However, I will point out that there has never been a positive post from the GNOME community about Pop!_OS. Ever. And there are numerous negative posts. It’s fine if there’s nothing good to say but continuously criticizing downstreams is also wrong and unnecessary.

    GNOME is one of many open source communities we work in. It is unique in that it’s the only one that publicly treats downstreams with such toxicity. It’s a waste of time and energy for all participants. I hope the community can improve in this respect.

    1. You would probably get more comments if you were more present in the community/contributing more. Looking to e.g Jeremy’s gitlab activity he looks like he contributed 2 merge requests in a year since he has created his account and he didn’t contribute at all to gitlab between August and April.

      1. I’m not seeking comments. I’m pointing out that there are only negative posts about Pop!_OS on the GNOME blog and that’s a poor and unnecessary way to treat downstreams. Do you disagree?

        Finally, if more collaboration and contributions are what’s desired, is continuous negative post about a project (that’s just over a year old) the way to encourage that project to participate?

        1. Your company called the upstream GTK theme ugly poo, is upstream supposed to respect that because you ship gnome (+ several unstable patched that upstream now had to support)?

  4. I can’t speak about the gnome contribution that popos does I can speak about contributions in general to the not only popos but also redox.

    Have any of you gnome developers taken any time to peruse the happenings of redox rust os and all the effort placed there?

    It’s not the undermine all the effort that gnome is making, but a different perspective that the redox developers are sharing and the redox developers are sharing a lot.

    Gnome is awesome.
    PopOs is awesome.
    Redox is awesome effort and work also.

    About all the criticisms made in this blog, please keep it constructive. Lots of hard-work is everywhere here.
    All the above 3 Gnome/Popos/Redox teams are gifted and doing their best with the time they do have. Please keep that in mind.

  5. Well, did you contact the people and had a discussion with them, or is this blogpost the first step towards that discussion? How is one-sided monologue scolding someone on the internet going to improve the situation? Would _you_ want to change your ways if somebody wrote a blogpost about you “doing it wrong” instead of a more constructive approach?

    I’m asking as a long-time GNOME user who was a little surprised to see such a post on Planet GNOME; I thought this stuff was mostly going on mailing lists.

  6. This is very amusing .

    So Perhaps System 76 should fork Debian instead of Ubuntu if Ubuntu is (as it seems) getting too slow at leeching from Debian.

    youtube-dl from the real upstream that is Debian unstable seems to be very recent. All hail the real upstream!

Comments are closed.

Leave a Reply to Jeremy Soller Cancel reply

Your email address will not be published. Required fields are marked *