I don't think anyone at the Arch project or the Debian project
would say that Arch is based on Debian.
It is certainly the case that their documentation is good, and
although not universally applicable to Debian packages, can be a
decent guide.
FYI, some of us have recently re-started an effort to improve the Debian Wiki. One of the things we need to establish (IMHO) is to determine what audience the wiki is *for*. For example, it serves a useful function for Developers, with clusters of pages for Debconfs, summers of code, etc.,
and well-maintained pages for some developer tools.
It's less clear how useful the current wiki is for users. I think many of us are inspired by how good the Arch Wiki is for users, and the Debian wiki falls far short of that. I guess we should try to improve it for users, but we don't have consensus on exactly how to do that, yet.
Suggestions welcome!
On Wed May 14, 2025 at 7:45 PM BST, Dan Ritter wrote:
I don't think anyone at the Arch project or the Debian projectACK
would say that Arch is based on Debian.
It is certainly the case that their documentation is good, and
although not universally applicable to Debian packages, can be a
decent guide.
FYI, some of us have recently re-started an effort to improve the Debian Wiki. One of the things we need to establish (IMHO) is to determine what audience the wiki is *for*.
one of the problems I see in the world of GNU/Linux is this tendency
to have "per-distribution" documentation for thing which are not
specific to a distribution, as evidenced by the fact that Debian users
often find the Arch wiki useful.
The most prominent issue I can see is that there is no unified
sense of chronology. That is, I can look at a page and not have
any idea whether it is correct for current Stable.
On Thu May 15, 2025 at 5:45 PM BST, Stefan Monnier wrote:
one of the problems I see in the world of GNU/Linux is this
tendency to have "per-distribution" documentation for thing which
are not specific to a distribution, as evidenced by the fact that
Debian users often find the Arch wiki useful.
I agree that the Debian Wiki should strive to document
Debian-specific stuff. I recently deleted (sort-of) the page
DotFiles¹, after a brief discussion on this list a month ago, because
it was out-of-date with respect to Greg's wiki² and not really
distribution specific (although there are distribution specific
quirks, that Greg documents).
[1] https://wiki.debian.org/DotFiles
[2] https://mywiki.wooledge.org/DotFiles
On 2025-05-16, Jonathan Dowland <jmtd@debian.org> wrote:
On Thu May 15, 2025 at 2:33 PM BST, Dan Ritter wrote:
The most prominent issue I can see is that there is no unified
sense of chronology. That is, I can look at a page and not have
any idea whether it is correct for current Stable.
That's what I said more succinctly. Keep the wikis up to date (I
thought it went without saying "for Debian stable," though there's
always a myriad of ways to be misunderstood but normally only one way
to be so).
Thank you. That is useful feedback, and I agree that we should be
clear about what version of Debian a given page (or section)
applies to. (And we should default to documenting Debian stable,
IMHO)
I suggested we establish a standard way to do this as part of
someone else's efforts to write fresh content guidelines¹. I should
pick that effort back up and finish it off.
[1] https://wiki.debian.org/MaythamAlsudany/DraftContentGuidelines/Discussion
On 2025-05-16, Jonathan Dowland <jmtd@debian.org> wrote:
On Thu May 15, 2025 at 2:33 PM BST, Dan Ritter wrote:
The most prominent issue I can see is that there is no unified
sense of chronology. That is, I can look at a page and not have
any idea whether it is correct for current Stable.
That's what I said more succinctly. Keep the wikis up to date (I thought
it went without saying "for Debian stable," though there's always a
myriad of ways to be misunderstood but normally only one way to be so).
Yes, keeping the wikis up to date for the current release would be
nice. But there isn't staff dedicated to keeping everything current,
so how about having a "last updated" or "last reviewed" date on each
page so people would have an idea of how current that page is.
The wiki engine automatically displays a "last modified" timestamp
(it's at the bottom, in the light gray footer box), but you won't
immediately know whether that update was a major content rewrite, or a
typo correction.
On 2025-05-20, Greg Wooledge <greg@wooledge.org> wrote:
On Tue, May 20, 2025 at 09:41:21 -0400, Lee wrote:
Yes, keeping the wikis up to date for the current release would be
nice. But there isn't staff dedicated to keeping everything current,
so how about having a "last updated" or "last reviewed" date on each
page so people would have an idea of how current that page is.
The wiki engine automatically displays a "last modified" timestamp (it's
at the bottom, in the light gray footer box), but you won't immediately know whether that update was a major content rewrite, or a typo
correction.
Yes, I thought wikis inherently comprehended a revision history.
FWIW I didn't find "keep it up to date" useful feedback.
FWIW I didn't find "keep it up to date" useful feedback.
Here's my view: replace each current page with a list of "per Debian
version" pages. So, when someone edits a page, they don't edit the "DebianBootstrap" page, but the "DebianBootstrap/trixie" page.
On Mon May 19, 2025 at 2:03 PM BST, Greg wrote:
On 2025-05-16, Jonathan Dowland <jmtd@debian.org> wrote:
On Thu May 15, 2025 at 2:33 PM BST, Dan Ritter wrote:
The most prominent issue I can see is that there is no unified
sense of chronology. That is, I can look at a page and not have
any idea whether it is correct for current Stable.
That's what I said more succinctly. Keep the wikis up to date (I
thought it went without saying "for Debian stable," though there's
always a myriad of ways to be misunderstood but normally only one
way to be so).
FWIW I didn't find "keep it up to date" useful feedback. One way of interpreting it is "delete out-of-date pages". In extremis I think
this would be a bad idea (but others may not agree).
Another interpretation is "edit out-of-date pages so they are no
longer out-of-date". We don't have enough person-power to do that at
the moment, and I doubt we ever will. So IMHO we need a more refined strategy.
Establishing conventions about which Debian version is described by
default (I'm sure there are those with a view that we should document
the latest package versions, rather than the latest Debian release),
and how we indicate if a section or page is applicable to a different version, and how an editor could mark a page as potentially
out-of-date or misleading (short of removing it entirely), I think
are useful ways forward.
On 2025-05-20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
FWIW I didn't find "keep it up to date" useful feedback.
Here's my view: replace each current page with a list of "per Debian version" pages. So, when someone edits a page, they don't edit the "DebianBootstrap" page, but the "DebianBootstrap/trixie" page.
All compendiums of knowledge are kept up to date (dictionaries, encyclopedias, etc).
To argue otherwise is nuts.
FWIW I didn't find "keep it up to date" useful feedback.
Here's my view: replace each current page with a list of "per Debian
version" pages. So, when someone edits a page, they don't edit the "DebianBootstrap" page, but the "DebianBootstrap/trixie" page.
On Tue May 20, 2025 at 4:04 PM BST, Stefan Monnier wrote:
FWIW I didn't find "keep it up to date" useful feedback.
Here's my view: replace each current page with a list of "per Debian version" pages. So, when someone edits a page, they don't edit the "DebianBootstrap" page, but the "DebianBootstrap/trixie" page.
A variation on this I prefer would be for the assumption to be that
all pages applied to the current stable release. There would be no
need for additional sub-pages for other releases by default unless
the material needed to differ for that release. If the differences
were really minor, they could be included in the main article, albeit
marked up to indicate for which release that section applied (e.g.
with an "info box"); if the cumulative differences were above some
threshold, instead a sub-page created.
On Tue May 20, 2025 at 4:04 PM BST, Stefan Monnier wrote:
A variation on this I prefer would be for the assumption to be that allFWIW I didn't find "keep it up to date" useful feedback.Here's my view: replace each current page with a list of "per Debian
version" pages. So, when someone edits a page, they don't edit the
"DebianBootstrap" page, but the "DebianBootstrap/trixie" page.
pages applied to the current stable release. There would be no need for additional sub-pages for other releases by default unless the material
needed to differ for that release.
In contrast my proposition means that when a new release happens we just
get a new set of pages, which start empty (this part can be done fully automatically) and can be filled progressively, which should be much
more amenable to crowdsourcing.
On Tue, May 20, 2025 at 16:38:16 -0400, Stefan Monnier wrote:
In contrast my proposition means that when a new release happens we just
get a new set of pages, which start empty (this part can be done fully
automatically) and can be filled progressively, which should be much
more amenable to crowdsourcing.
I have multiple problems with this proposal.
1) Most pages don't actually become obsolete with a new Debian release.
The number of incompatible changes in a new release is usually
pretty small.
2) Re-creating the *entire* wiki every time there's a new release is
a stupidly ridiculous amount of effort. Not just the initial act
of moving creating a whole new versioned page for every existing
nonversioned page -- which by *itself* is already ridiculous --
but then there's the step of rewriting the whole wiki.
Rewriting.
The.
Whole.
Wiki.
Do you even hear yourself?
3) Who's this "crowd" that you're planning to "crowdsource" all of
this work onto?
Greg Wooledge [2025-05-20 16:49:28] wrote:
On Tue, May 20, 2025 at 16:38:16 -0400, Stefan Monnier wrote:
In contrast my proposition means that when a new release happens we just >> get a new set of pages, which start empty (this part can be done fully
automatically) and can be filled progressively, which should be much
more amenable to crowdsourcing.
I have multiple problems with this proposal.
1) Most pages don't actually become obsolete with a new Debian release.
The number of incompatible changes in a new release is usually
pretty small.
2) Re-creating the *entire* wiki every time there's a new release is
a stupidly ridiculous amount of effort. Not just the initial act
of moving creating a whole new versioned page for every existing
nonversioned page -- which by *itself* is already ridiculous --
but then there's the step of rewriting the whole wiki.
Rewriting.
The.
Whole.
Wiki.
Do you even hear yourself?
3) Who's this "crowd" that you're planning to "crowdsource" all of
this work onto?
I'm quite aware of these holes in my proposal.
I do think they can be plugged to some extent.
E.g. when a page doesn't exist but a page for an older version does
exist, we could show that older page with a note saying something like
"this is for version FOO so it may be outofdate, but maybe it's still relevant".
4) You want to rewrite not only the WIKI CONTENT, but the WIKI ENGINE too.
Greg <curtyshoo@gmail.com> wrote:2025-05-16 09:16:47)
On 2025-05-16, Jonathan Dowland <jmtd@debian.org> wrote:It's not quite the same. What Dan is asking for is that each wiki page
On Thu May 15, 2025 at 2:33 PM BST, Dan Ritter wrote:That's what I said more succinctly. Keep the wikis up to date (I
The most prominent issue I can see is that there is no unified
sense of chronology. That is, I can look at a page and not have
any idea whether it is correct for current Stable.
thought it went without saying "for Debian stable," though there's
always a myriad of ways to be misunderstood but normally only one way
to be so).
should identify when it was updated and for which named release(s) of
Debian it is valid. So even if it's out of date it may be useful to
somebody, or it may be possible to deduce what's wrong for the current
stable in some circumstances.
Thank you. That is useful feedback, and I agree that we should be
clear about what version of Debian a given page (or section)
applies to. (And we should default to documenting Debian stable,
IMHO)
I suggested we establish a standard way to do this as part of
someone else's efforts to write fresh content guidelines¹. I should
pick that effort back up and finish it off.
[1]
https://wiki.debian.org/MaythamAlsudany/DraftContentGuidelines/Discussion typically I see this in the footer: MaythamAlsudany/DraftContentGuidelines/Discussion (last modified
Why propose yet again the exact thing I proposed upthread (that you
required me to spell out with ludicrous explicitness and that you
described as unhelpful), as if you've arrived at some epiphany?
What is your problem, anyway?
It's not quite the same. What Dan is asking for is that each wiki
page should identify when it was updated and for which named
release(s) of Debian it is valid. So even if it's out of date it
may be useful to somebody, or it may be possible to deduce what's
wrong for the current stable in some circumstances.
typically I see this in the footer: MaythamAlsudany/DraftContentGuidelines/Discussion (last modified 2025-05-16 09:16:47)
in my opinion should be at or near the Header
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:22:03 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,060 |
| Messages: | 6,416,691 |