[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: We might need a better wording for our release page



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.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: