4 ms·

I made a thing that ubuntu now (recently) includes in their distro. Canonical employees have filed tickets with me about this thing. Responses to it, by me, are

I made a thing that ubuntu now (recently) includes in their distro. Canonical employees have filed tickets with me about this thing. Responses to it, by me, are generally ignored for many weeks/months. They've patched the thing in weird ways without contributing anything back (upstream as it were). This does not seem like 1) a good model for floss developers to give a shit about Canonical, 2) a good model for Canonical to support (non-corporate?) users

jdhendrickson 8y ago
You aren't secretly JWZ are you? hah Seems to be a pattern of behavior.
cperciva 8y ago
They've patched the thing in weird ways without contributing anything back (upstream as it were). I've had this problem with both Debian and Ubuntu. Sometimes the patches they apply are good, sometimes bad; but I wish they at least had a social norm of "contact the upstream project and offer them the patches". It's annoying when the first I hear about a patch is when a user contacts me to complain that something is broken.
- e12e 8y ago
  For Debian - would you say that's mostly package owner dependent, or more tied to the policy of "bug-fix without api change only" in stable? Or just overall poor culture of communicating with upstream - when upstream != maintainer of Debian package?
  - cperciva 8y ago
    None of the cases I've seen have been related to the policy of avoiding API changes in stable. Most of them seem to be instances of "user files a bug with Debian; package maintainer adds a patch to address user's complaint but doesn't relay the bug report or the patch upstream".
alxlaz 8y ago
> 2) a good model for Canonical to support (non-corporate?) users What on Earth made you think Canonical cares about supporting non-corporate users :-)?
julian-klode 8y ago
Hey craftyguy. I assume you are talking about networkd-dispatcher? I understand if you feel like your responses are being ignored. I was focused on other things the past weeks, I'd love to be more responsive. WRT patching things in weird ways and not contributing back, I don't understand it. We are shipping three patches in Ubuntu: (1) Changing from Arch's /etc/conf.d to the Debian/Ubuntu /etc/default directory. (2) Switch form /etc/networkd-dispatcher to /usr/lib/networkd-dispatcher. (3) Running with --run-startup-triggers by default. (1) and (3) are distro-specific things. Sure (1) could be made an option somewhere or something, but that sounds more complicated than just fixing the path to match the policy. For (2), I opened a bug about supporting both directories. The most important part for us was having the ability to package our hooks in /usr for the 18.04 release, though, so I had to quickly patch that in. I fully intend to support both paths and then send you a pull request, but I think it's clear that a pull request at the current time would not be worthwhile. I hope that this addresses your concerns.

jdhendrickson 8y ago

You aren't secretly JWZ are you? hah Seems to be a pattern of behavior.

cperciva 8y ago

They've patched the thing in weird ways without contributing anything back (upstream as it were). I've had this problem with both Debian and Ubuntu. Sometimes the patches they apply are good, sometimes bad; but I wish they at least had a social norm of "contact the upstream project and offer them the patches". It's annoying when the first I hear about a patch is when a user contacts me to complain that something is broken.

e12e 8y ago
For Debian - would you say that's mostly package owner dependent, or more tied to the policy of "bug-fix without api change only" in stable? Or just overall poor culture of communicating with upstream - when upstream != maintainer of Debian package?
- cperciva 8y ago
  None of the cases I've seen have been related to the policy of avoiding API changes in stable. Most of them seem to be instances of "user files a bug with Debian; package maintainer adds a patch to address user's complaint but doesn't relay the bug report or the patch upstream".

alxlaz 8y ago

> 2) a good model for Canonical to support (non-corporate?) users What on Earth made you think Canonical cares about supporting non-corporate users :-)?

julian-klode 8y ago

Hey craftyguy. I assume you are talking about networkd-dispatcher? I understand if you feel like your responses are being ignored. I was focused on other things the past weeks, I'd love to be more responsive. WRT patching things in weird ways and not contributing back, I don't understand it. We are shipping three patches in Ubuntu: (1) Changing from Arch's /etc/conf.d to the Debian/Ubuntu /etc/default directory. (2) Switch form /etc/networkd-dispatcher to /usr/lib/networkd-dispatcher. (3) Running with --run-startup-triggers by default. (1) and (3) are distro-specific things. Sure (1) could be made an option somewhere or something, but that sounds more complicated than just fixing the path to match the policy. For (2), I opened a bug about supporting both directories. The most important part for us was having the ability to package our hooks in /usr for the 18.04 release, though, so I had to quickly patch that in. I fully intend to support both paths and then send you a pull request, but I think it's clear that a pull request at the current time would not be worthwhile. I hope that this addresses your concerns.