Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Winding down my Debian involvement

michael.stapelberg.ch

Post reply on HN
Print view View original

221–230 of 238 posts

Re: Winding down my Debian involvement

#221

Post by rleigh »

j16sdiz wrote: post #174
rleigh wrote: post #79

Earlier quoted context omitted.

It's not just about "low quality" bug reports. The entire system is baroque and messy to use even for experts. I've been using it for 2+ decades now. As a maintainer, I frequently needed to change bug tickets. Tags, versions, dependencies, and other details. All need doing through the control@ email interface. Changes can take over half an hour to be processed and acknowledged. It's inefficient and tedious, and prone…

Why download the mbox? Don't bugnumber@bugs.debian.org work?

Because you might need to reply to a specific email with all the same people CCd in who wouldn't necessarily be copied in by the bugnumber address. It also includes the appropriate message ID to make threading work. And you can quote the necessary bits to put the reply in context.

The fact that you need to jump through these hoops to respond so that people will see your reply is another reason why it's a really painful and inefficient workflow.

Re: Winding down my Debian involvement

#222

Post by rleigh »

sanxiyn wrote: post #156
josteink wrote: post #92

Earlier quoted context omitted.

And unlike most distros which were around back then, Debian is still here today, so it must be good for something . That said, I agree anything Debian (and thus Ubuntu too) and FSF feels awkwardly baroque to work with these days. Old email-based systems, bickering over politics and minor issues rather than the subject at hand, for weeks or months... and no standard CI?!? With all that I too find myself spending my ti…

What is the problem with old email-based systems? This is an honest question.

There's no problem with systems which allow interaction by email. It can be handy, and if you like that, then the Debian BTS is convenient for responding to bugs as a maintainer. However, email-only systems which don't offer any other methods of interaction can be problematic.

email-only interaction can be massively inefficient. For larger changes, I might need to change the severities, tags, and follow up to dozens of bugs. For every metadata change I make, I need to check the reply to make sure the change took place. That means manually tying together sent emails with BTS replies and repeating any which failed.

I used to track all this on large pieces of paper! I shouldn't need a manual system to manage my interaction with an issue tracking system. When I press submit in any other system, the effect is immediate. This is hugely costly in terms of time and effort to do really trivial and mundane things. It's one thing to do it once, but what happens when you make 30 changes and have to wait 20 minutes for each request to round-trip? It's a logistical nightmare which can take several hours to complete.

If I was to highlight a single problem with the Debian BTS, it's that there was a failure to acknowledge its inefficiencies and look at other systems. The criticisms raised in this thread aren't new; they were known 15+ years back. There's a reason why the others are not using email as their primary mode of interaction, and it's a shame the BTS didn't get a decent web frontend to make it more efficient as well as more accessible.

Re: Winding down my Debian involvement

#223

Post by JoshTriplett »

debiandev wrote: post #197
genghizkhan wrote: post #171

Earlier quoted context omitted.

If the systemd discussion has taught me anything about Debian governance, getting everyone to agree is going to be a pain. Far easier to let it be.

Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.

No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".

Re: Winding down my Debian involvement

#224

Post by rleigh »

forty wrote: post #175

I have a naive question (I'm a long time Debian user, but never really tried to contribute): why isn't all the Debian in a single git repository? I'm not suggesting to vendor all the third party code but only all the packaging information, like, say, libreelec does (and I assume many others)

It's all down to history. When Debian was started, individual maintainers owned their packages completely, and they were often not kept under version control. This was a practical necessity for distributed development in the mid '90s. They uploaded the source and binaries when they uploaded a new Debian package version, but the actual source packages weren't necessarily under any sort of version control other than the Debian archive storing the uploaded versions.

Today, keeping packages under version control is considered good practice, but even today it's not mandatory as far as I'm aware.

While other systems, like the BSD ports, are in a single repository, this complete separation has had its advantages. The system is almost completely modular, with all the interdependencies explicitly documented. It's easy to add third-party packages. Look how easy it is to add extra BSD ports packages. You have to fork the entire thing because the repo doesn't just include the packages, it includes all the build infrastructure. This makes building third-party ports a bit more of a pain, because it wasn't considered important, while for Debian it was a fundamental design goal. On the flip side, making a patch for the BSD ports is the same for every single package and it takes just a few minutes to attach it to a bugzilla ticket.

Re: Winding down my Debian involvement

#225

Post by rleigh »

wbl wrote: post #112
rleigh wrote: post #77

Earlier quoted context omitted.

Likewise for the BSD ports. There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change. Debian's approach made sense at the time. Developers wh…

We've had CVS for years.

True, but it's not just the version control that's the important part. It's the infrastructure around it.

Today, when you submit e.g. a homebrew PR, it gets comprehensively tested by CI builds, including rebuilding and testing all reverse dependencies on every supported platform version. The BSD ports changes are backed by poudriere builds of the entire collection, again on multiple versions.

Services like GitHub and GitLab allow one to hook in all sorts of stuff and greatly improve the ease of submission of large- and small-scale changes, as well as making thorough testing and review both possible and accessible. Older projects are stuck with older entrenched tools and infrastructure, and haven't taken advantage to newer ways of doing things which newer projects have been able to adopt wholesale. The Debian tooling and infrastructure is certainly dated, but it's also of extremely high quality and very robust.

Re: Winding down my Debian involvement

#226

Post by Conan_Kudo »

bubblethink wrote: post #220
Conan_Kudo wrote: post #200

Earlier quoted context omitted.

Actually, since EPEL is often backports from Fedora, many people elect to keep them up to date with what's shipped in Fedora, so it tends to do better than other counterparts. The closest counterpart is SUSE's PackageHub, which is often seeded by stuff going into openSUSE Leap that isn't part of SLE itself.

Just saw your other comment about Fedora. Thanks for Fedora and EPEL. I was just pointing out that EPEL would benefit from some recognition as a semi-official but ultimately unsupported repo from RH. Technically RH already has 'optional' channels which are already in that category, but EPEL should really be that. Some communication channel between RH and EPEL and QA so that stuff doesn't break on RHEL point releases…

We'd all love that. It's funny, because Red Hat does regularly source content from EPEL to pull into RHEL for various products, which is where these issues come from.

I would love it if Red Hat were to give it proper recognition. I honestly don't know why they haven't yet...

Re: Winding down my Debian involvement

#227

Post by passthejoe »

perlgeek wrote: post #116
jcoffland wrote: post #66

I've been using Debian for over 10 years and I still love it as a user. But as a developer, I find it extremely frustrating. I've several times attempted to figure out how to package my open-source projects [1] [2] for Debian but the process is a nightmare. As I understand it, I first have to find someone with appropriate privileges to mentor me. I should be able to just submit a potential package for review. Then th…

> Then there is a ton of documentation on creating packages but which 300 page guide is the right one to use is unclear. And which set of packaging tools should I use? I've run into the same problems, though I've only wanted to build packages for my own use, or company-internal use. I think I've understood now how packaging is supposed to work, and have written a guide, shameless plug: http://leanpub.com/debian/c/hn…

Thanks for this!

Re: Winding down my Debian involvement

#228

Post by Conan_Kudo »

UncleEntity wrote: post #123
ansible wrote: post #16

I've been using Debian / Ubuntu for many years, as much due to inertia and familiarity as anything else. And I have a lot of respect for the project. If I wanted to start being a contributor to a distribution, which one would be the best to dive in to?

> If I wanted to start being a contributor to a distribution, which one would be the best to dive in to? I tried to contribute a package to Fedora once upon a time...gave up in frustration after a while since it went nowhere after a bit of hoop jumping.

I'm sorry you felt that way. All I can say is that we've done a lot of work in recent years to drastically improve the quality of life for new contributors, especially packagers!

The process is pretty well documented here: https://fedoraproject.org/wiki/Join_the_package_collection_m...

If you have issues, feel free to hop into any of the Fedora communication channels[1][2][3][4][5] and ask for help.

[1]: https://fedoraproject.org/wiki/Communicating_and_getting_hel...

[2]: https://fedoraproject.org/wiki/Telegram

[3]: https://discord.gg/fedora (Yes, Discord!)

[4]: https://discussion.fedoraproject.org/

[5]: https://fedoraforum.org/ (Unofficial, but a strong, helpful group!)

Re: Winding down my Debian involvement

#229

Post by mattdm »

bubblethink wrote: post #220
Conan_Kudo wrote: post #200

Earlier quoted context omitted.

Actually, since EPEL is often backports from Fedora, many people elect to keep them up to date with what's shipped in Fedora, so it tends to do better than other counterparts. The closest counterpart is SUSE's PackageHub, which is often seeded by stuff going into openSUSE Leap that isn't part of SLE itself.

Just saw your other comment about Fedora. Thanks for Fedora and EPEL. I was just pointing out that EPEL would benefit from some recognition as a semi-official but ultimately unsupported repo from RH. Technically RH already has 'optional' channels which are already in that category, but EPEL should really be that. Some communication channel between RH and EPEL and QA so that stuff doesn't break on RHEL point releases…

Are you a RHEL customer? If so, telling your salespeople this would not hurt. Just sayin' :)

Re: Winding down my Debian involvement

#230

Post by debiandev »

JoshTriplett wrote: post #223
debiandev wrote: post #197

Earlier quoted context omitted.

Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.

No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".

This is a misunderstanding of how Debian works.
Post reply on HN