But it has been hard to read trough this comments and realize how much ignorance about what Debian is, how it works, what the Debian bug tracker is, what a voluntary-based project is, and to read some assertions and prepotency around in HN
If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
Debian is not a startup. Debian is not an elastic architecture in the cloud to support/pay-for traffic peaks. Debian may benefit from your solutions and resources, if you're so good. Debian isn't perfect.
The Debian bugtracker maybe not the web application I could write in 2016, but I'm conscious on how much work has been around it, and it's ecosystem, how much I'm in debt with the Debian bug tracker as opensource user, and how much should I THANK to the people who did work on it, who works on it and who uses it, and even translates it
Depressing to sometimes find great threads, and sometimes loose the time with subjective views, inexperienced reviews, false and incomplete assertions, haters, and mass style thinking.
I'm scared to imagine on hands of what kind of people there are technological choices... or to think that people gets influenced by content creators of this level... maybe I'm lucky and most of those opinions I dislike, are not from real engineers/hackers, but from lost re-users, and people without humility repeating what they find shocking, like a child of 3 years.
> If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
Are you really saying that the only way to contribute to Debian's success is to directly fix problems yourself? Community feedback (in the form of bug reports, comments on forums, mailing list discussion participation, etc) is hugely important in most every open source project; dismissing that is foolish at best and harmful at worst.
> Ok, so Debian is a developers-only distribution?
This might not be a bad characterization of where it sits now.
If you want a hand-holding "user-friendly" (and I use the term advisedly, based on the common, flawed conception of what a "user" is), create one based on Debian, leveraging the Debian tools and packages and processes to make an Ubuntu or Mint or something else.
Debian isn't a meta-distribution. It is a distribution in its own right. However, it is commonly used as the foundation for a different distribution, with different goals and different ways of relating to the world. Debian itself remains unchanged, ready to base another distribution off of, and another, and another...
> Ok, so Debian is a developers-only distribution?
For all practical purposes, I'd say yes. GNU/Linux as a PC operating system for non-programmers is a lost cause. Sure, some organizations make it work, but it probably requires a lot of technical support; they'd probably be better off using Android tablets and/or Chromebooks if they need something less expensive than a Windows PC, let alone a Mac. And when non-programmers need web hosting, they don't reach for a DigitalOcean droplet; they use a shared host that offers an abstraction over the LAMP stack like cPanel, or an even more non-developer-friendly service like Squarespace.
"$PROJECT is not a startup. $PROJECT is not an elastic architecture in the cloud to support/pay-for traffic peaks. $PROJECT may benefit from your solutions and resources, if you're so good. $PROJECT isn't perfect."
I have half a mind to just add this to every single project's README in the https://github.com/redis-store organization.
>$PROJECT may benefit from your solutions and resources, if you're so good. $PROJECT isn't perfect.
May I suggest using "$PROJECT may benefit from your solutions and resources. $PROJECT isn't perfect." - "if you're so good" could be interpreted as "if you're good enough".
The problem with "you can go fix it if you want" is that the barrier to "fixing it" is very high, even with such great things as #debian-mentors.
I fully understand the need for all the process and policy but it can be very difficult to get things fixed in Debian without talking to the right people or attending the right conferences.
Agreed, what you can do on first contact, is not always what you would like to do.
I didn't mean it's the only and single way to change something in Debian... the subtle of my message was, that complaining outside the project, does not help to anybody, and forms subjective opinions on persons that didn't have them.
Today, someone at $work that never did write perl, was complaining on perl and Larry Wall just for laughs, I told him: when Mr Google calls you to speak about _your_ language, when the world is full of mirrors of libraries written by all kind of persons and companies for _you_ language, please, come back, and we have some laughs.
It seems that some people needs to "attack third parties together" to feel "in society".
As a usability expert, I can tell you that: "If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one." is why it will NEVER be the year of Debian on the desktop.
Users use computers to compute - "using linux" is not a primary task. I'm not saying open source should compromise on their core values, but Debian could stand to take a page out of, say, the Tor Project's book and focus harder on usability.
Keep in mind the target audience of txutxu's post: this is Hacker News! His reply is to a group of people who are, if not all experts in technology related fields, likely capable of contributing to the Debian project in some meaningful way.
Debian is an amazing project that is where it is because so many people decided to "go fix it." Not everybody who uses Debian needs to have that mentality, but anybody on HN who is complaining about the project and wants to see it improved should consider translating that opinion into action.
This isn't to say that txutxu worded his response in the most tactful manner, of course, but you have to consider it in context.
> Mozilla releases new Firefox releases every 6 to 8 weeks.
In parallel of these rapid releases [...]
One of the fun differences between the various organizations I've worked for is the differing ideas of how frequently releases should happen and what is considered "fast" and "slow" in different places. I've seen release cycles measured in weeks and those measured in years. I'm sure there are places that release every N days. How people get used to some particular cadence and start believing that it's the only proper (or possible) way! One of the achievements I'm most proud of is helping a group make a difficult transition from a long, irregular cadence to a fast, predictable one. Going from a release process of "Release when company leadership subjectively thinks it's ready" to "Release every 4 weeks on the day" can at first rattle some people who are attached to The Way We've Always Done It, and it requires more discipline in terms of development practices, testing, feature creep, etc. But it can be done!
Not saying a faster or slower cycle is needed for Debian or Mozilla (it would depend on a huge number of factors), but your release cadence shouldn't be considered some immovable law of nature.
I find it very interesting that they are adopting a different release schedule for Firefox than the rest of Debian stable. People that care about fast release cycles probably really just care about few minor things being up to date, while administrators don't care about which programs/libraries make problems when updating as long as the total amount of breakages in a certain time isn't too high.
This is probably due to the specific nature of browser upgrades, which is the reason why firefox and chrome went to 6-week autoupgrade schedules for clients: people expect a hell of a lot from their browsers; troubleshooting a fractured version environment in such a complex field is next to impossible; important security updates need to be pushed.
So you end up with two main releases for the browser, one is the standard one that updates every six weeks, and the other has a more stable 'extended support' environment that just gets bugfixes, for places that can't easily deal with changes very often (like a business or education SOE). Debian stable usually lasts for about two years, and modern browser releases would find that impossible to support.
> but your release cadence shouldn't be considered some immovable law of nature.
I agree, but I think it mostly depends on the product. If you have a bulletproof software implementation of, say, a finances managing system, then you will rarely need to update it -- as long as it has no bugs then the users will be happy with it.
On the flip side, if you have a program that has to be both secure, but also have a lot of features, and is used by a lot of people, then I think you will find yourself releasing every few days -- even if you just stick to staying on top of any vulnerabilities and bugs that could occur.
Even if you are adding features, some software products are such that customers simply can't/won't upgrade at a pace of more than a few times a year (if that). Anything mission critical will need to go through validation, acceptance testing, you'll want to check that integrations with other products are unaffected, etc. Especially if the organization is understaffed in the IT department, then these sorts of upgrades can easily lose priority to the 100 other things on their plates.
Funny, I've been running Debian since 2007. I mainly got hooked on their 'testing' branch since it is just "always up to date".
But I always get people looking over my shoulder and asking "what the heck is 'iceweasel'. To which I explain the whole issue of Debian was distributing a patched version of Firefox with their OS back in ~2007 era and Mozilla, for trademark reasons, said you can't modify the browser and still distribute it with the official logos and name. Which lead to Iceweasel... but then a few years later Mozilla changed the license terms so now I guess here we are....
> I mainly got hooked on their 'testing' branch since it is just "always up to date".
Note that testing doesn't get the same level of security support as stable: "Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern." [1]; more details: [2], [3], [4].
To speed it up even more you would need to follow the unstable/testing pages on the security tracker and file bugs to get maintainers to do fixes and do NMUs when maintainers are on vacation or missing.
A few years ago some extensions wouldn't work with iceweasel. I forget which ones, and why, but it basically boiled down to: "this extension is meant for firefox". I wish I could remember which ones those were to see if it really was just a naming issue.
It's interesting that the Paul brings up the trademark license clause regarding for-pay distribution.
If you are using the Mozilla Mark(s) for the unaltered binaries you
are distributing, you may not charge for that product.
While it restricts a freedom that Debian is unlikely to exercise, it's still a restriction. Presumably, that makes the trademark license indigestible to the Debian foundation?
I'm fairly sure when you are buying physical copies of Linux distributions you are buying the service of compiling and copying it and providing physical media, the box, any manuals, etc. The source code at a minimum must be made freely available to others. That is, they aren't charging for the code delivered, but the delivery itself and the physical media.
When included in a larger work it would seem that you can argue you are charging for everything else and providing Firefox for free kind of like Microsoft and IE.
Also, Debian is really lacking some more modern bug management / issue tracking system.
It might be useful to provide e-mail interface for it, but I fail to see why it also can't be managed from some site at the same time instead of limiting it to read only view.
Although GitHub Issues has a lot of issues, for the singular reason that you can opt-in and opt-out of notifications on particular subjects I find it vastly more useful than most bug trackers.
Is there a good open-source GitHub alternative that implements this feature?
OTRS and RT allow you to watch a ticket. Thus you can chose to be notified for changes to a ticket (opt-in).
I know of no particular opt-out feature, though at least for OTRS it would be rather easy to write an add-on that makes you watch all new tickets in a particular queue, of which you could opt-out by stopping to watch a ticket.
https://tracker.debian.org/pkg/iceweasel is getting there. The bug tracker has lots of integration with other Debian systems. I'd say it'd be a huge project to upgrade/replace.
Interesting, thanks. I'm using that tracker site quite often to see progress of various packages. But I didn't know it will be useful for managing bugs as well.
By the way, something happened to the fonts on that site a few day ago. They look worse now.
> On the contrary, Debian having a longer release cycle (about every two
years), release cycles don't align.
Then change your release cycle. Seriously, it's not that hard. Say that browsers are different and get released frequently. Create a firefox-lts package that is updated at the beginning of your Debian release cycle -- and never again. Let the firefox package be the firefox package, updated as frequently as upstream wants.
This is already kind of the case. Debian stable tracks the Firefox ESR releases, updating when a new one comes out. If you want the Firefox frequent releases, you get them with backports from the Debian Mozilla team (out of the main archive).
(For the more adventurous desktop users, they can also use Debian unstable for the frequent releases. Unstable isn't unstable in terms of your machine falling over. Rather, there is a lot of package churn, and you need to use something like "sudo aptitude upgrade --visual-preview" when upgrading to ensure that you don't try to upgrade something in the middle of a big package transition before everything is finished and ready in the package repo.)
If you don't like the 2 year release cycle, use Ubuntu, which is Debian-based. Debian maintains such long release cycles because the tolerance for bugs and incompatibilities are smaller than other linux distros. For long-lived applications or applications that have long planning periods Debian is ideal. NASA uses Debian, because their projects are measured in years, have low tolerances for bugs, and are developed to last 5+ years. Simply put, Debian's release model is for a different use-case than your typical web development project
It's really very nice to just throw Ubuntu 14.04 on everything and not worry about it. I can use my machines for doing work and not have to waste a lot of time dealing with whatever the latest churn is.
Literally right below that it says: "To address this packaging issue, once a ESR cycle is over, Debian has
been accepting uploads of new ESR releases in the stable release."
As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.
But most users don't want the ESR version, they want the latest non-ESR version, yes, you can go and get it from mozilla but some users find this inconvenient.
Debian implements the comical definition of Bureaucracy really well. Missing the forest for the trees and thinking that every single piece of software is built and released the same way.
For a Linux distro that has been around so long, it's mind boggling they still don't understand that. Wine used to have the same problem - Wine's cycle had the Chrome-like cycle before Chrome even existed. Release every 2 weeks like clockwork. Releases are not any more or less stable than the previous one, but they implement more functionality and a newer release will almost always be better than an older one. Wine's "Stable" releases are meaningless, other than "We spend a month working on bugfixes/regression instead of features before a stable release".
I think this is a misunderstanding of the goals of Debian Stable.
The purpose is not to get a stable release of each upstream project and build a release from those. The goal is to get any release of each upstream project, test it for a few months to ensure there are no show-stopping bugs and to document the known ones, and then freeze it.
The goal is not to ensure lack of bugs, it's to ensure stability, that is, that no new bugs appear or existing behaviours change.
The goal is to allow the sysadmin to configure the system, test it - working around existing bugs - and leave it running, being reasonably sure that stuff won't randomly break until he upgrades the major version, while remaining secure.
Which means exciting new regressions every two weeks! When I used wine it was definitely the case that certain applications(games) worked better with specific wine versions so a continuous release cycle could result in breaking a working application. That's something users of stable are trying to avoid.
If a user wants the latest version of a package you can always install it manually.
We still release every 2 weeks on the dot. Next release is on Friday.
And our stable branch is changing to yearly releases! We are going to do a code freeze every Fall and release in late Fall or early Winter. It is also going to receive more regular backports of "safe" improvements, so slow distros like Debian can benefit from important fixes. We've already had a dot-dot stable release this year!
> For a Linux distro that has been around so long, it's mind boggling they still don't understand that.*
They definitely do understand that - they also offer more packages than any other x86 operating system. It's just that they have a reason for doing it their way. The operating system is meant to provide a stable base, and the user can then select particular software for more frequent upgrades by adding their own target repositories. Or using make.
Debian is one of the two major linux distros that other distros source from. It's a bit weird to suggest that they don't really get how software is developed.
Surprisingly, Chromium is always up to date on the Debian stable release. Why can't they do the same for Iceweasel/Firefox? keep the ESR version and a version that matches upstream latest releases, but there's probably something I'm missing here.
I keep finding it puzzling that Debian would opt to maintain a fork of Firefox, while at the same time go all in with systemd because it would be too much effort to maintain something else.
Debbugs works great for being last updated 12 years ago. It's main interface is email, after all, so the web interface is read-only. I think the real issue here is the hardware it's running on.
Perhaps I'm being unfair —because I know how the sausage is made— but if it looks like it's generated by Perl (clunky late-90s design, obvious interactive parts, filter, logins, etc) it probably scales like a squirrel carrying watermelons. (One at a time is okay.)
Debian should definitely do more to stop this from happening but this isn't the first time a HN link to a clunky old webapp has taken it down.
HN should just do this by default; meaning if traffic gets results in a site response time dropping, it should know that that Google cache or the like is up, or provide a cache itself.
Readit News
This is great news for few of us.
But it has been hard to read trough this comments and realize how much ignorance about what Debian is, how it works, what the Debian bug tracker is, what a voluntary-based project is, and to read some assertions and prepotency around in HN
If you see ANYTHING wrong with Debian, go fix it, or shut up and go to sell your stuff to another one.
Debian is not a startup. Debian is not an elastic architecture in the cloud to support/pay-for traffic peaks. Debian may benefit from your solutions and resources, if you're so good. Debian isn't perfect.
The Debian bugtracker maybe not the web application I could write in 2016, but I'm conscious on how much work has been around it, and it's ecosystem, how much I'm in debt with the Debian bug tracker as opensource user, and how much should I THANK to the people who did work on it, who works on it and who uses it, and even translates it
Depressing to sometimes find great threads, and sometimes loose the time with subjective views, inexperienced reviews, false and incomplete assertions, haters, and mass style thinking.
I'm scared to imagine on hands of what kind of people there are technological choices... or to think that people gets influenced by content creators of this level... maybe I'm lucky and most of those opinions I dislike, are not from real engineers/hackers, but from lost re-users, and people without humility repeating what they find shocking, like a child of 3 years.
Feel free to downvote without reasoning why.
Are you really saying that the only way to contribute to Debian's success is to directly fix problems yourself? Community feedback (in the form of bug reports, comments on forums, mailing list discussion participation, etc) is hugely important in most every open source project; dismissing that is foolish at best and harmful at worst.
"Talk about the problem, where you can fix it, not just a comment in a third party forum".
I was after a telephone discussion and maybe I was a little bit harsh.
It's not that bug reports are not useful, it's that if you follow the debian manual, you don't need the web interface for reporting bugs...
People working on web technologies, use to blame opensource projects a lot, without any help.
Ok, so Debian is a developers-only distribution?
> Feel free to downvote without reasoning why.
I didn't bother, but "Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted." https://news.ycombinator.com/newsguidelines.html
Absolutely not. You can use Debian and help improve Debian without being a developer and even without being very technical.
https://www.debian.org/intro/help
This might not be a bad characterization of where it sits now.
If you want a hand-holding "user-friendly" (and I use the term advisedly, based on the common, flawed conception of what a "user" is), create one based on Debian, leveraging the Debian tools and packages and processes to make an Ubuntu or Mint or something else.
Debian isn't a meta-distribution. It is a distribution in its own right. However, it is commonly used as the foundation for a different distribution, with different goals and different ways of relating to the world. Debian itself remains unchanged, ready to base another distribution off of, and another, and another...
Well, as an user of a openly licensed system, you are free to use the source. As well as, you're free to don't use it :)
But regarding voluntary work, it's useless and ugly to harm and bash it, without helping the cause.
Didn't know that guidelines, thanks, and sorry.
For all practical purposes, I'd say yes. GNU/Linux as a PC operating system for non-programmers is a lost cause. Sure, some organizations make it work, but it probably requires a lot of technical support; they'd probably be better off using Android tablets and/or Chromebooks if they need something less expensive than a Windows PC, let alone a Mac. And when non-programmers need web hosting, they don't reach for a DigitalOcean droplet; they use a shared host that offers an abstraction over the LAMP stack like cPanel, or an even more non-developer-friendly service like Squarespace.
I have half a mind to just add this to every single project's README in the https://github.com/redis-store organization.
May I suggest using "$PROJECT may benefit from your solutions and resources. $PROJECT isn't perfect." - "if you're so good" could be interpreted as "if you're good enough".
I fully understand the need for all the process and policy but it can be very difficult to get things fixed in Debian without talking to the right people or attending the right conferences.
I didn't mean it's the only and single way to change something in Debian... the subtle of my message was, that complaining outside the project, does not help to anybody, and forms subjective opinions on persons that didn't have them.
Today, someone at $work that never did write perl, was complaining on perl and Larry Wall just for laughs, I told him: when Mr Google calls you to speak about _your_ language, when the world is full of mirrors of libraries written by all kind of persons and companies for _you_ language, please, come back, and we have some laughs.
It seems that some people needs to "attack third parties together" to feel "in society".
Users use computers to compute - "using linux" is not a primary task. I'm not saying open source should compromise on their core values, but Debian could stand to take a page out of, say, the Tor Project's book and focus harder on usability.
Debian is an amazing project that is where it is because so many people decided to "go fix it." Not everybody who uses Debian needs to have that mentality, but anybody on HN who is complaining about the project and wants to see it improved should consider translating that opinion into action.
This isn't to say that txutxu worded his response in the most tactful manner, of course, but you have to consider it in context.
And I don't mean that metaphorically. Ubuntu literally is Debian with usability enhancements.
One of the fun differences between the various organizations I've worked for is the differing ideas of how frequently releases should happen and what is considered "fast" and "slow" in different places. I've seen release cycles measured in weeks and those measured in years. I'm sure there are places that release every N days. How people get used to some particular cadence and start believing that it's the only proper (or possible) way! One of the achievements I'm most proud of is helping a group make a difficult transition from a long, irregular cadence to a fast, predictable one. Going from a release process of "Release when company leadership subjectively thinks it's ready" to "Release every 4 weeks on the day" can at first rattle some people who are attached to The Way We've Always Done It, and it requires more discipline in terms of development practices, testing, feature creep, etc. But it can be done!
Not saying a faster or slower cycle is needed for Debian or Mozilla (it would depend on a huge number of factors), but your release cadence shouldn't be considered some immovable law of nature.
So you end up with two main releases for the browser, one is the standard one that updates every six weeks, and the other has a more stable 'extended support' environment that just gets bugfixes, for places that can't easily deal with changes very often (like a business or education SOE). Debian stable usually lasts for about two years, and modern browser releases would find that impossible to support.
I agree, but I think it mostly depends on the product. If you have a bulletproof software implementation of, say, a finances managing system, then you will rarely need to update it -- as long as it has no bugs then the users will be happy with it.
On the flip side, if you have a program that has to be both secure, but also have a lot of features, and is used by a lot of people, then I think you will find yourself releasing every few days -- even if you just stick to staying on top of any vulnerabilities and bugs that could occur.
But I always get people looking over my shoulder and asking "what the heck is 'iceweasel'. To which I explain the whole issue of Debian was distributing a patched version of Firefox with their OS back in ~2007 era and Mozilla, for trademark reasons, said you can't modify the browser and still distribute it with the official logos and name. Which lead to Iceweasel... but then a few years later Mozilla changed the license terms so now I guess here we are....
Note that testing doesn't get the same level of security support as stable: "Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern." [1]; more details: [2], [3], [4].
[1] https://wiki.debian.org/DebianTesting#Considerations
[2] https://wiki.debian.org/Status/Testing
[3] https://www.debian.org/security/faq#testing
[4] http://secure-testing-master.debian.net/
https://bugs.debian.org/725934
To speed it up even more you would need to follow the unstable/testing pages on the security tracker and file bugs to get maintainers to do fixes and do NMUs when maintainers are on vacation or missing.
https://security-tracker.debian.org/tracker/status/release/u...https://security-tracker.debian.org/tracker/status/release/t...
Deleted Comment
Also, Debian is really lacking some more modern bug management / issue tracking system.
It might be useful to provide e-mail interface for it, but I fail to see why it also can't be managed from some site at the same time instead of limiting it to read only view.
Is there a good open-source GitHub alternative that implements this feature?
What do you mean by that? Doesn't every bug tracker implement that feature?
I know of no particular opt-out feature, though at least for OTRS it would be rather easy to write an add-on that makes you watch all new tickets in a particular queue, of which you could opt-out by stopping to watch a ticket.
By the way, something happened to the fonts on that site a few day ago. They look worse now.
Then change your release cycle. Seriously, it's not that hard. Say that browsers are different and get released frequently. Create a firefox-lts package that is updated at the beginning of your Debian release cycle -- and never again. Let the firefox package be the firefox package, updated as frequently as upstream wants.
(For the more adventurous desktop users, they can also use Debian unstable for the frequent releases. Unstable isn't unstable in terms of your machine falling over. Rather, there is a lot of package churn, and you need to use something like "sudo aptitude upgrade --visual-preview" when upgrading to ensure that you don't try to upgrade something in the middle of a big package transition before everything is finished and ready in the package repo.)
Deleted Comment
As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.
For a Linux distro that has been around so long, it's mind boggling they still don't understand that. Wine used to have the same problem - Wine's cycle had the Chrome-like cycle before Chrome even existed. Release every 2 weeks like clockwork. Releases are not any more or less stable than the previous one, but they implement more functionality and a newer release will almost always be better than an older one. Wine's "Stable" releases are meaningless, other than "We spend a month working on bugfixes/regression instead of features before a stable release".
The purpose is not to get a stable release of each upstream project and build a release from those. The goal is to get any release of each upstream project, test it for a few months to ensure there are no show-stopping bugs and to document the known ones, and then freeze it.
The goal is not to ensure lack of bugs, it's to ensure stability, that is, that no new bugs appear or existing behaviours change.
The goal is to allow the sysadmin to configure the system, test it - working around existing bugs - and leave it running, being reasonably sure that stuff won't randomly break until he upgrades the major version, while remaining secure.
Which means exciting new regressions every two weeks! When I used wine it was definitely the case that certain applications(games) worked better with specific wine versions so a continuous release cycle could result in breaking a working application. That's something users of stable are trying to avoid.
If a user wants the latest version of a package you can always install it manually.
And our stable branch is changing to yearly releases! We are going to do a code freeze every Fall and release in late Fall or early Winter. It is also going to receive more regular backports of "safe" improvements, so slow distros like Debian can benefit from important fixes. We've already had a dot-dot stable release this year!
http://source.winehq.org/git/wine.git/shortlog/refs/heads/st...
They definitely do understand that - they also offer more packages than any other x86 operating system. It's just that they have a reason for doing it their way. The operating system is meant to provide a stable base, and the user can then select particular software for more frequent upgrades by adding their own target repositories. Or using make.
Debian is one of the two major linux distros that other distros source from. It's a bit weird to suggest that they don't really get how software is developed.
Deleted Comment
Debian's update system does drive me nuts, but I have never run a Debian server for longer then 6 months.
Please be considerate when linking to webapps. If there's a static or cached version available, please post that.
In this case Debian's tracker mirrors everything to publicly mirrored mail servers (which are static), ie: https://www.mail-archive.com/debian-bugs-dist@lists.debian.o...
Come on man.
Debian should definitely do more to stop this from happening but this isn't the first time a HN link to a clunky old webapp has taken it down.