5 ms·

A (Partial) Defense of Debian

49 points by andrewshadura 8y ago

andrewshadura 8y ago
(This is a reaction to https://news.ycombinator.com/item?id=19353010 https://news.ycombinator.com/item?id=19353010)
smacktoward 8y ago
> I remember the days before we had reportbug. Over and over and over again, I would get bug reports from users that wouldn’t have the basic information needed to investigate. reportbug gathers information from the system: package versions, configurations, versions of dependencies, etc. A simple web form can’t do this because it doesn’t have a local agent. You control the operating system. Couldn't you build a web form that integrates with a local agent?
- Boulth 8y ago
  Actually using Native Messaging it's not that hard. For example Mailvelope (OpenPGP browser extension) uses Native Messaging to talk to locally running GnuPG.
- Conan_Kudo 8y ago
  In Fedora, we have a web form configuration with a basic bug reporting template in the Red Hat Bugzilla (which we share with Red Hat, since it's useful to cross-link bugs between RHEL and Fedora). In addition, we created the Automatic Bug Reporting Tool (ABRT)[1] to handle program and system crashes and report them so developers can look at them. We have hooks in various parts of the system to help generate useful bug reports of serious issues with crash data, machine information, and so on. They get submitted as private bugs by default to the bug tracker, and the Fedora retrace server[2] kicks in to request the debuginfo data remotely to get traces as needed and include those in the bug report. ABRT also helps you strip sensitive data (if any) from information being sent remotely before sending it. You can see pretty charts about the crash analysis too: https://retrace.fedoraproject.org/faf/summary/ https://retrace.fedoraproject.org/faf/summary/ [1]: https://abrt.readthedocs.io/en/latest/ https://abrt.readthedocs.io/en/latest/ [2]: https://fedoraproject.org/wiki/Features/RetraceServer https://fedoraproject.org/wiki/Features/RetraceServer
twblalock 8y ago
Reading this defense makes me think Debian is stuck in the past and will have trouble attracting skilled developers and maintainers in the future. The section on personal preferences is one example of this. Very few people new to the project would prefer debbugs and a text-based mail client over a Github workflow.
- theobeers 8y ago
  I'm also curious how many newer contributors would see friction in simply "firing up a web browser." edit: I may have read that part of the post uncharitably, if what the author meant was continually switching between the browser and the command line. Still, the sentence stuck out to me.
  - blihp 8y ago
    I suspect that for many of the existing developers, it's deeper than that. A subset of the devs work a significant fraction of their time offline so firing up a web browser isn't going to work for them at all. Also, another subset of the devs would find adding a dependency to github or any other non-free[1] service antithetical to the Debian ethos. Realistically, I don't see them switching away from text based files with at least the option of an offline workflow on the back-end, which makes sense to me. That said, I really do wish they'd understand that to people who don't live and breath the Debian workflow, the existing front-end tooling is painful to use and antiquated and prioritize updating it. It is possible to create a much nicer front-end user experience on top of what currently exists. [1] From the FSF/Debian perspective, no-cost is not free https://en.wikipedia.org/wiki/Gratis_versus_Libre https://en.wikipedia.org/wiki/Gratis_versus_Libre
    - Conan_Kudo 8y ago
      This is actually the case in Fedora, too. That's why we created Pagure[1] and HyperKitty[2]. Pagure provides a service similar to GitHub and GitLab, while also supporting mostly offline workflows. Pull request metadata, issues, documentation, and of course the code, are stored as Git repos. You can clone them, do work, and push them back, and Pagure will act on them appropriately. Or you can operate from the web UI if you prefer, and ignore the fact that the data is stored as Git repositories internally. HyperKitty adds web forum-style conversation views and functionality to a mailing list, allowing people who are uncomfortable with handling everything by mail to still follow and respond to threads and be part of the conversation. Both of these show it's possible to support the old guard while making it possible to welcome fresh blood and adapt to their preferences. For better or worse, it's an "adapt or die" situation. Debian isn't adapting, which is not good. As an aside, Debian nearly did deploy Pagure. The community voted for it, and then the DSAs (Debian System Administrators) decided on using GitLab using GitLab Omnibus (not even the GitLab packaged in Debian!) anyway, which upset a fair number of friends I have who are Debian Developers. But all of them said that they were powerless to influence change, which seriously speaks to some kind of broken process here, where the "most powerful" group of people in Debian feel powerless about stuff like this. [1]: https://pagure.io/pagure https://pagure.io/pagure [2]: https://hyperkitty.readthedocs.io/en/latest/ https://hyperkitty.readthedocs.io/en/latest/
lucideer 8y ago
> If it’s Github, it’s going to look like this: > Go to the website for the thing, click fork > Now clone that fork or add it to my .git/config, hack, and commit > Push the commit, go back to the website, and submit a PR > Github’s email integration is so poor that I basically have to go back to the website for most parts of the conversation. I can do little from the comfort of mu4e. > Remember to clean up my fork after the patch is accepted or rejected. > Compare that to how I’d contribute with Debian: > Hack (and commit if I feel like it) > Type “reportbug foo”, attach my patch > Followup conversation happens directly in email where it’s convenient to reply I've actually seen this type of thing quite often in criticisms of GH/web-based workflows, etc. And frankly, they're all complete madness. The leaps of logic made in the above bullets are so enormous they can't not be wilful. The author is really stretching. 1. The equivalents of "going to the website", forking, adding to local git config, are all skipped for the Debian workflow; it is assumed one has already set the project up locally. For a new project, these steps are 100% guaranteed to be more complex for Debian (or any project not on a website with fork-like features). 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? 3. Pointing out that you should clean up branches in your fork is superfluous. 4. The second step in the Debian workflow leaves out two things: you haven't included the setup of the reportbug cli, and—since we're clearly more comfortable with a cli than with a browser—ignores the fact that there are equivalents for interacting with the GH API without ever going near a browser.
- irishsultan 8y ago
  > 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? That feels like an unfair remark, creating a pull request is only the first step in either workflow, having good email integration is still important for every other step
- tracker1 8y ago
  Beyond all of that, if it's a trivial change, click edit on the upstream repository, edit the file, save+Pr and you're done... the fork is all inline. I submit docs changes all the time right in the github web ui. Cleanup for forks isn't always great, I can admit that, but you can create an org for temporary stuff, and just nuke everything there on occassion and put your forks there for temps.
pmoriarty 8y ago
So what Linux distros are people moving to when they leave Debian?
- JohnFen 8y ago
  I haven't left Debian, but I am evaluating other options. The two top contenders for me right now are Slackware and making the leap out of Linux entirely and into BSD.
- twblalock 8y ago
  I moved to Fedora.
deleted 8y ago
[deleted]

49 points by andrewshadura 8y ago

(This is a reaction to https://news.ycombinator.com/item?id=19353010 https://news.ycombinator.com/item?id=19353010)

> I remember the days before we had reportbug. Over and over and over again, I would get bug reports from users that wouldn’t have the basic information needed to investigate. reportbug gathers information from the system: package versions, configurations, versions of dependencies, etc. A simple web form can’t do this because it doesn’t have a local agent. You control the operating system. Couldn't you build a web form that integrates with a local agent?

Boulth 8y ago
Actually using Native Messaging it's not that hard. For example Mailvelope (OpenPGP browser extension) uses Native Messaging to talk to locally running GnuPG.
Conan_Kudo 8y ago
In Fedora, we have a web form configuration with a basic bug reporting template in the Red Hat Bugzilla (which we share with Red Hat, since it's useful to cross-link bugs between RHEL and Fedora). In addition, we created the Automatic Bug Reporting Tool (ABRT)[1] to handle program and system crashes and report them so developers can look at them. We have hooks in various parts of the system to help generate useful bug reports of serious issues with crash data, machine information, and so on. They get submitted as private bugs by default to the bug tracker, and the Fedora retrace server[2] kicks in to request the debuginfo data remotely to get traces as needed and include those in the bug report. ABRT also helps you strip sensitive data (if any) from information being sent remotely before sending it. You can see pretty charts about the crash analysis too: https://retrace.fedoraproject.org/faf/summary/ https://retrace.fedoraproject.org/faf/summary/ [1]: https://abrt.readthedocs.io/en/latest/ https://abrt.readthedocs.io/en/latest/ [2]: https://fedoraproject.org/wiki/Features/RetraceServer https://fedoraproject.org/wiki/Features/RetraceServer

twblalock 8y ago

Reading this defense makes me think Debian is stuck in the past and will have trouble attracting skilled developers and maintainers in the future. The section on personal preferences is one example of this. Very few people new to the project would prefer debbugs and a text-based mail client over a Github workflow.

theobeers 8y ago
I'm also curious how many newer contributors would see friction in simply "firing up a web browser." edit: I may have read that part of the post uncharitably, if what the author meant was continually switching between the browser and the command line. Still, the sentence stuck out to me.
- blihp 8y ago
  I suspect that for many of the existing developers, it's deeper than that. A subset of the devs work a significant fraction of their time offline so firing up a web browser isn't going to work for them at all. Also, another subset of the devs would find adding a dependency to github or any other non-free[1] service antithetical to the Debian ethos. Realistically, I don't see them switching away from text based files with at least the option of an offline workflow on the back-end, which makes sense to me. That said, I really do wish they'd understand that to people who don't live and breath the Debian workflow, the existing front-end tooling is painful to use and antiquated and prioritize updating it. It is possible to create a much nicer front-end user experience on top of what currently exists. [1] From the FSF/Debian perspective, no-cost is not free https://en.wikipedia.org/wiki/Gratis_versus_Libre https://en.wikipedia.org/wiki/Gratis_versus_Libre
  - Conan_Kudo 8y ago
    This is actually the case in Fedora, too. That's why we created Pagure[1] and HyperKitty[2]. Pagure provides a service similar to GitHub and GitLab, while also supporting mostly offline workflows. Pull request metadata, issues, documentation, and of course the code, are stored as Git repos. You can clone them, do work, and push them back, and Pagure will act on them appropriately. Or you can operate from the web UI if you prefer, and ignore the fact that the data is stored as Git repositories internally. HyperKitty adds web forum-style conversation views and functionality to a mailing list, allowing people who are uncomfortable with handling everything by mail to still follow and respond to threads and be part of the conversation. Both of these show it's possible to support the old guard while making it possible to welcome fresh blood and adapt to their preferences. For better or worse, it's an "adapt or die" situation. Debian isn't adapting, which is not good. As an aside, Debian nearly did deploy Pagure. The community voted for it, and then the DSAs (Debian System Administrators) decided on using GitLab using GitLab Omnibus (not even the GitLab packaged in Debian!) anyway, which upset a fair number of friends I have who are Debian Developers. But all of them said that they were powerless to influence change, which seriously speaks to some kind of broken process here, where the "most powerful" group of people in Debian feel powerless about stuff like this. [1]: https://pagure.io/pagure https://pagure.io/pagure [2]: https://hyperkitty.readthedocs.io/en/latest/ https://hyperkitty.readthedocs.io/en/latest/

lucideer 8y ago

> If it’s Github, it’s going to look like this: > Go to the website for the thing, click fork > Now clone that fork or add it to my .git/config, hack, and commit > Push the commit, go back to the website, and submit a PR > Github’s email integration is so poor that I basically have to go back to the website for most parts of the conversation. I can do little from the comfort of mu4e. > Remember to clean up my fork after the patch is accepted or rejected. > Compare that to how I’d contribute with Debian: > Hack (and commit if I feel like it) > Type “reportbug foo”, attach my patch > Followup conversation happens directly in email where it’s convenient to reply I've actually seen this type of thing quite often in criticisms of GH/web-based workflows, etc. And frankly, they're all complete madness. The leaps of logic made in the above bullets are so enormous they can't not be wilful. The author is really stretching. 1. The equivalents of "going to the website", forking, adding to local git config, are all skipped for the Debian workflow; it is assumed one has already set the project up locally. For a new project, these steps are 100% guaranteed to be more complex for Debian (or any project not on a website with fork-like features). 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? 3. Pointing out that you should clean up branches in your fork is superfluous. 4. The second step in the Debian workflow leaves out two things: you haven't included the setup of the reportbug cli, and—since we're clearly more comfortable with a cli than with a browser—ignores the fact that there are equivalents for interacting with the GH API without ever going near a browser.

irishsultan 8y ago
> 2. "Github's email integration is so poor": why have we brought up email here. Github integrates PR links into the server response of the git push itself. You have actual cli integration here, shown in the output of git. Why bring up email? That feels like an unfair remark, creating a pull request is only the first step in either workflow, having good email integration is still important for every other step
tracker1 8y ago
Beyond all of that, if it's a trivial change, click edit on the upstream repository, edit the file, save+Pr and you're done... the fork is all inline. I submit docs changes all the time right in the github web ui. Cleanup for forks isn't always great, I can admit that, but you can create an org for temporary stuff, and just nuke everything there on occassion and put your forks there for temps.

pmoriarty 8y ago

So what Linux distros are people moving to when they leave Debian?

JohnFen 8y ago
I haven't left Debian, but I am evaluating other options. The two top contenders for me right now are Slackware and making the leap out of Linux entirely and into BSD.
twblalock 8y ago
I moved to Fedora.

deleted 8y ago

[deleted]