Re: We might need a better wording for our release page
Justin B Rye <[email protected]> Tue, 31 Dec 2024 14:26:42 +0000
| Newsgroups | gmane.linux.debian.devel.publicity |
|---|---|
| Message-ID | <[email protected]> |
Gerardo Ballabio wrote: > Hello all, my 2 cents: > > Since the goal is to avoid ambiguity, it may be helpful to define > exactly which ambiguities we want to avoid. > > As I understand, this started with Andreas' report of a discussion > where he argued that "testing is not a release" (and unstable isn't > either). So this is one piece of information that we want to convey -- > and that would seem to rule out such wording as "stable, testing and > unstable may be called suites, versions, distributions *or releases*". Well, that isn't exactly what any of the suggestions says, but remember that what it says is true: all those terms *are* used, and readers may need to know that. But what we're looking for is a way of introducing the kind of thing that stable/testing/unstable are with one *un*ambiguous and preferably self-explanatory term (that we can then parenthetically mention also has near-synonyms). The obvious choice would be "suite", but that's not much use for introducing them because we'd have to stop and define it first, and whatever word we find to explain it would be the word we should have used to introduce the concept in the first place. Another option that hasn't been explored yet is to introduce them as "branches" of Debian development (the word I wish we'd adopted as the official term in the first place). But people always seem to avoid that for some reason; is it perhaps technically inappropriate in some way that's obvious to developers? Debian always has at least three developmental branches in active maintenance: the "stable", "testing" and "unstable" suites (also referred to as releases or distributions). And then we never need to use the word "branch" again. > Another question (or bunch of questions) that we're trying to answer > is: which kind of users should run testing, why would they want to, > and what should they expect (e.g., no timely security fixes, no > promise that it won't eat your data, etc.) > > Are there other points that we're trying to drive home? The page mostly says what it was intended to say; we're just rephrasing it to say it better, but if you've got any extra ideas, feel free to mention them. There might be some more material that could be promoted from the FAQ, though that does seem a bit dated.