
A (Partial) Defense of Debian - andrewshadura
http://changelog.complete.org/archives/9971-a-partial-defense-of-debian
======
twblalock
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
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
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
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/)

------
smacktoward
_> 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?

~~~
Conan_Kudo
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)

------
lucideer
> 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.

~~~
IronBacon
> _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)._

Naah, you only need to know the URL of the Debian package's _.dsc_ file that
you want to patch, and pass it to the _dget_ command, it will download the
application tarball, the Debian patches and the dsc file.

You can find the _dsc_ URLs on the Debian packages tracker site:
tracker.debian.org

~~~
lucideer
How do I get to the Debian packages tracker site? Do I need to open a browser?

On a more serious note: you open with "Naah", but then you do go on to
describe steps that the author neglected to include in the bullet points. My
only point was: the author goes out of their way to make the comparison
imbalanced.

~~~
IronBacon
I was objecting the _" Debian workflow is more complex than a forking"_ part.

In reality it's even simpler than what I described (if you don't remove the
_deb-src_ lines from your apt source config like I do). If you want to modify
a Debian package you only need to use "source" instead of "install" for the
package you need, for example "apt source curl" will download the tarball,
diff and dsc file for the curl package in the working directory, no browser
involved. ^__^;

I use the tracker site when I need to build some packages from unstable or
experimental, usually recent libraries that I couldn't find on
backports.debian.org.

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

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

~~~
JohnFen
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.

