Differences between revisions 10 and 11
Revision 10 as of 2006-07-26 13:19:52
Size: 5593
Editor: HolgerLevsen
Revision 11 as of 2006-07-26 19:09:22
Size: 5580
Editor: ?aba
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
For the html-front end, users should see the "current" articles (10?) on For the html-front end, users should see the "current" 10 (configurable per user) articles on
Line 17: Line 17:
[Q: Also scroll back to "older" pages on the standard page, or only
per month?]
Line 20: Line 18:
The rss-style page includes the most recent 30 [Q: right number?] entries.
[Q: also scroll back in rss-style]
The rss-style page includes the most recent 30 entries.
Line 31: Line 28:
[Q: Syntax for tags? Only "all but not marked this and that" and "none [Q: Syntax for categories? Only "all but not marked this and that" and "none
Line 64: Line 61:
  * http://en.wikipedia.org/wiki/Textile_(markup_language)
  * MoinMoin-style (like this wiki)

This page is about times.debian.net - currently a service in preparation.

It is related to something like dot.kde.org, and should contain all the nice small items that are too unimportant for debian-news@lists.debian.org, but are important enough that we should announce them somewhere. One of the key items is that more people should have the right to add articles there.

All on this page is just a first draft, feel free to adjust it.

User Interface

From the user's point of view, it is basically "just another html/rss page". Articles on ?DebianTimes should be categorized, and users can decide which categories they want to see.

For the "end users" there are two "simple" interfaces: A rss-style one (or rather many - there is more than one standard), and a normal html-style one.

For the html-front end, users should see the "current" 10 (configurable per user) articles on the front page, and be able to scroll back in history to older months.

The rss-style page includes the most recent 30 entries.

Both the html pages and the rss feeds should be "configureable" for the end users to decide which categories they want to see and which not.

Articles are shown as http://times.debian.net/123-etch-relased.html (but this is just a sample now, nothing behind it :) ), but the server ignores anything after the first -, so that users see what the article is about without forcing complex article handling on the server side.

[Q: Syntax for categories? Only "all but not marked this and that" and "none but only marked so and so"? Or more (complex)?]


  • weekly-news (via rss-syndication)
  • news [should the "normal" news be syndicated and be put in a different category?]
  • security-announce (via rss-syndication)
  • events announcements
  • event-reports
  • success-stories
  • derivatives
  • release-related
  • regional categories: europe, america, asia, [what for .au+.nz?] [split ca/us vs latin-america?]

[add some more?]

[any reasonable ones via rss-syndication, like people-behind-debian]


Articles can be submitted via two ways: Per signed mail, and by an http-interface. This allows the submitter to work the way (s)he prefers to work, and the server to numerate the articles.

Articles contain meta-information, on the mail way via Pseudo-Headers. These information includes Tags, Subject, Short Subject (for the article name), Language and, if appropriate, publication date; articles not containing a publication date are published right now.

The body itself is written in some wiki-style enriched text [FIXME: which one?].


(Translation will probably be added after the first prototoype.)

  • There are files for the different languages, each language in a directory (rationale: you don't need to checkout all)
  • Any commit is sent out by mail to the people who want it, a list per language (same rationale)
  • The translations are marked which version of the original file they reflect; so, it's relativly easy to see where to work on.
  • The published-date of the different translations is the same by default, but can be overwritten.
  • Usually commits for the original language should be done "in time" relative to the publication-date so that the translators have enough time to follow up; by default, an article is published 36 hours after submission. Also, translators could mark their translation "not yet done"
  • The translators interface would be, in free choice for the translator, be via mail, rcs (e.g. svn) and web.
  • In cases of syndicated articles, translation (if existend) is automatically syndicated as well.

Website Backend

The rcs checkout is updated. A (fast) index of important stuff exists. A "last changed"-time for all articles is put somewhere on the file system.

The articles are put by the system in some rcs (svn?), translation is put in the same file in the other languages directory. Fixes to the article can also be commited via the rcs-interface.

Any article has two dates: The semantically date, taken from the date-header and put on the website, pubDate etc, and the technically date, taken from last checkin and put into lastBuildDate. If the article changes content, update the semantical date as well; otherwise (e.g. spelling corrections), don't change it. Also, the article has a guid of http://times.d.n/$lang/$id, so that it stays the same even if the short title changes.

Any changes to an article are sent out by mails to the submitters/translators/admins.

When a client requests some page (i.e. a special combination of tags), it is looked up whether this combination is already cached and at least as current as the last change. If so -> deliver.

Otherwise, the page is created by parsing the index and - if required - the relevant articles. Code from planet.debian can be take to do this without too much effort. The page is stored, and, if there are too many stored pages (remember, with 10 categories we can have 3^10 pages, or 22 (or so, depending on which combinations we allow), which might be really many different pages), some old non-standard ones are removed (non-standard means: not with all tags enabled, and probably something like "everything except dwn").

The index should contain information about name of the article, date, tags, url, so that it's enough to generate overview pages.