Debian Web Pages TODO List
- Fairly important items
- Content negotiation issues
- Mirroring issues
- Wrong URLs
- Miscellaneous requests
- Bug reports
Fairly important items
In addition to the items mentioned below, please have a look at the list of open bugs for the www.debian.org pseudopackage.
The sitemap needs to be reviewed to see if all the pages are listed there, and reorganize the different sections.
Maybe we should emphasize some major pages by making them <strong> or <em>.
We should agree if we want a link to the sitemap in the home page (and the rewritten pages that use similar template), and where (bug #982344).
Make a page to credit donations. This idea would need to be discussed. Currently significant donations are credited publishing a blog post in the Debian blog or via a News announcement.
All port specific information should be in the port pages. More of a long-standing wishlist that can't ever be fixed. :)
Review the ports listed as unmaintained in the port.maintainers file and fix them.
Import the sh port pages.
Writing an intro to something like Debian is not an easy job. You really need to give some thought into how you split up all the (interconnected) issues involved.
Some pages have been reviewed or rewritten recently (2021) but some others would need review (mainly the "about" page, and have a look at the index of that section to see if it can be simplified/reorganized).
All the vendors web sites need to be checked to see that they actually contribute. They should also be checked after each major release of Debian.
Please coordinate this work with the people behind firstname.lastname@example.org
Consultants should be pinged from time to time to see that they are still active and maintain the list current.
Please coordinate this work with the people behind email@example.com - you may also want to keep an eye on the Debian consultants mailing list.
Most of the events-related information is written now in wiki pages, it would be nice to review all this section together with the Events wiki pages, and update accordignly. Please coordinate with the Events team and the Debian LocalGroups Team to do this work.
Help for maintaining the list of books of Debian is very appreciated. Please contact firstname.lastname@example.org to see how can you help. There are some pending bugs: #317140 Display the license for Debian books, #363496 www.debian.org/doc/books should list books publication year
Figure out if we should keep basic+votebar templates, instead of just one template ("votepage" or something). There is a pending bug: #364913 - Vote-Pages should be build with more templates (easier translating/maintaining).
/security/ and lts/security
A great amount of the Debian web pages are the security advisories. It would be nice to think about moving the older ones (more than five years old?), that won't get translations or changes anymore, to be static files so they are not rebuilt with every template change. This idea needs to be discussed together with the Security team.
Collect remaining missing representatives of Debian in other places, verify/maintain the current ones.
Periodically check that the list of teams and members is current (particularly, the ones that are not delegated).
Code all the remaining best current practices.
Content negotiation issues
The content negotiation system has several flaws that might make some people give up on our site. However, we can't do much about this. Most of it is caused by clients sending non-RFC strings in the Accept-Language header, which makes Apache go bezerk and apply some of its illogical methods of serving smallest available files.
When given "*" in the Accept-Language header, the first available page will be served, and that's most likely not English, rather Arabic or Chinese. This is especially problematic when the user's language preference is a two-part language code (like "en-ca" or "nl-BE") followed by a "*".
Apache 1.3 sticks with the RFC here. Apache 2.0's code will imply a en or nl respectively, but it will be low priority so it probably won't help with e.g. "en-ca, fr-ca, *".
Also, when there exists a file of unknown language, i.e. an unrecognized foo.*.html file with no AddLanguage or LanguagePriority setting, and when the client sends an Accept-Language which contains only unavailable languages, the former file will be served.
This happened most often with the /releases/potato/i386/install page, because there's a Slovak variant of it and we didn't have that language set up in Apache because there's no web site translation in Slovak. We've alleviated the problem by including sk in the Apache config files, but as usual, changes don't propagate to all of the mirrors fast.
Sites are supposed to create the file mirror/timestamps/<host>. Jay has made scripts that check the date in this file for each mirror so we can know when a mirror is out of date, see mirror/timestamps/*.py.
We should reduce the number of web mirrors in Europe and increase the number of mirrors on other, less connected continents.
Making all mirrors pushed (from www-master if possible) is also a goal.
Making sure whether each mirror has correct Apache configuration is a pain, but there doesn't seem to be a way around that. Phil Hands suggested that the "AddLanguage" stuff is put into a wgettable file and that we make a Perl script that would automatically update people's Apache config files.
All links into the archive should allow the user to select the download
site. The master mirror list could be used to keep the list of mirrors up
to date (maybe even using a script). See
The mirror list is maintained by the people at email@example.com.
Links to external pages have to be checked if they are still correct. James Treacy has written a small Python script for this purpose. Frank Lichtenheld is currently maintaining the script, the (daily updated) results can be found at https://www-master.debian.org/build-logs/urlcheck/. Broken links have to be removed. This is more of a permanent task.
Deal with these as you wish.
If we had cgi.debian.org on a less used and faster host, we could have more dynamic content on the web pages.
Javier suggested making DDP pages account for translations, automatically.
I'd rather like to see a note on the security pages like:
Please note that we cannot guarantee that an intruder gets access to our servers since they are connected to the internet. In such a case an evil third party could potential modify uploads to security.debian.org and modify web pages containing MD5 sums. We are, however, trying our best to prohibit this. Please be advised that there is no 100% security, only improvements to the current situation.
Joey should rephrase it probably. :)
Should be added to /security/faq.
"Vernon Balbert" <firstname.lastname@example.org> suggested we make it clear which kernel version is used in the latest version of Debian.
Matti Airas <email@example.com> suggested "doing language selection with Apache mod_rewrite. Instead of having to explicitly go to https://www.debian.org/intro/about.en.html (or some mirror), I could go to https://www.debian.org/en/intro/about, which mod_rewrite then could replace with the correct url." Note that this would require additional hacks in order not to break relative links.
Chris Tillman suggested:
There is often confusion about which machines Debian supports and which we don't, yet. There is a bewildering array of machines, not to mention network cards, displays, mice, video cards, sound cards, port types, and so forth which an individual system might mix-and-match. Many of the Ports pages are out of date.
Debian supports a *lot* of systems. I think it would make sense to start trying to list which ones, specifically. Also, it would be really nice to know which ones aren't supported, both for new would-be users and for developers as a todo list.
I think the easiest way to achieve this, would be to provide a web page where people could enter in their system components, preferably chosen from a list of known components with an 'other' capability. Then, they could also enter a thumbs-up or thumbs-down, on Debian on that architecture. Also any specific problems.
Then after submission of the user's hardware specs, the system can show a (dated) list of previous user's experiences with those components.
We should also need to sprinkle pointers to this page into the install documentation, FAQs, probably even put a link on the front Debian page.
You can find a current TODO list in the Git repository.
The scripts are currently maintained by Frank 'djpig' Lichtenheld and Martin 'Joey' Schulze.
Please submit anything else to our mailing list.