Debian Web Pages TODO List
- Fairly important items
- Content negotiation issues
- Mirroring issues
- Wrong URLs
- Miscellaneous requests
- Bug reports
/donations and /partners/
Make a page for old donations, we don't want to forget the past ones, but they'd clutter up the page of current donations. Same for partners.
Separate huge chunks of non-translatable data from the donations page. See /mirror/sponsors for a start.
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.
This page should be shortened and have the more detailed information in links. There has been a suggestion that we create an advocacy page with links to other free projects that Debian supports.
One example is licenses. I [treacy?] wrote a bit about them, but it really should be moved to its own page (see intro/license_disc.wml). We need to convince people that some licenses are better than others. Hmmm sounds like this should be linked from the advocacy page too.
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.
A new page as mentioned above. The LPF needs to be linked from here (this is what started the idea of an advocacy page).
This should probably be created only when someone has time to redo all the intro documents. I [treacy?] have a lot of ideas on this and will do it myself if I get enough time.
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.
Another solution would be to move it to a database-driven system. There's already some sort of an internal database that only Craig knows about.
This page is being maintained by Craig Small (firstname.lastname@example.org)
This needs to be split up. (by continent, perhaps by country too)
Too much redundant stuff is left in the files translators touch; the same thing with .data files that we (treacy with some help from joy) did to security/ should be done here. Plus, this would make a single location where we change whether an event is past or current, which is a major hassle.
The tags for title, author, language, url, and available should be separated from the translatable portion of the page.
Get the secretary to (help) maintain these pages.
Figure out if we should keep basic+votebar templates, instead of just one template ("votepage" or something).
The scripts are currently maintained by Frank 'djpig' Lichtenheld and Martin 'Joey' Schulze.
Move this out of ports because they is not a Linux port (beowulf already removed). (Rename /ports/, too?)
Maybe we should emphasize some major pages by making them <strong> or <em>.
"We might want to put a note on lists.debian.org, pointing out that Debian reserves the right to archive any mail that comes into Debian." -- David Starner
There's now a note to that effect in /MailingLists/.
Around 2001-05-30 Apache on lists.d.o / cgi.d.o decided not to accept any arguments to its CGIs. Restarting it helped. Go figure.
Find the <moreinfo> entries for older years that contain mentions of lists-archives instead of including text from it or even linking to it, and correct it.
There are many advisories in 1997 and early 1998 that lack even the basic extra information -- find it and document it. Somehow. :)
Change the pages to have 'fixed in' info in a tag instead of page body, so that we can check for that tag in the template and not display 'Fixed in:' if it's empty.
Make the x86 port pages more useful... somehow :)
Split it up by section? Perhaps, if it grows too much...
This is already partially remedied by having various https://lists.debian.org/foo pages include a sub/unsub form.
Make a note about the anti-abuse check.
Collect remaining missing representatives of Debian in other places, verify/maintain the current ones.
Code all the remaining best current practices.
Document about cvs to git
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.
users/. Make the latter use the toc template.
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.
Please submit anything else to our mailing list.