On Mon, Apr 12, 2004 at 05:58:57PM -0600, Monique Y. Mudama wrote:
> On 2004-04-12, Adam Aube penned:
> > Monique Y. Mudama wrote:
> >
> >> Well, "more unstable than the stable distribution" takes a lot longer
> >> to type and wouldn't fit on a CD volume label =P
> >
> > What about "current", then?
>
> This would encourage people to use the unstable distribution, which by
> definition isn't considered ready for prime time. The truth is that
> there are tradeoffs; a one-word name just isn't going to capture those
> tradeoffs. If anything, the right term for unstable might be "head" or
> "tip" -- or would that be experimental?
or "breach"? :) just kidding.
it's important to note that the present branding scheme
(unstable / testing / stable) is certainly ACCURATE from the
point-of-view of the programmers and script-writers -- but for
the public-at-large, those terms seem MYSTERIOUS and engender
frequent explanations and lectures on this very list (enough to
warrant a FAQ, which a debian-newbie is unlikely to locate or to
read). often it seems like we have to dip into DAMAGE CONTROL
MODE simply because a newbie didn't "grok" the release naming
scheme.
so maybe a "public-oriented name scheme" is worthy of
consideration. that is, we could cautiously and considerately
select appropriate names for the releases that make sense to the
public at large, and:
1) not have to answer this question again!
2) improve dissemination of debian as folks are more
likely to get the release they really want
3) watch the ranks grow and grow and grow...
here i brainstorm to conjure up some naming scheme possibilities
(referring to current status as of 13 apr 2004):
sid -- alternatives to "UNSTABLE":
- "UNKNOWN"
- "DANGEROUS"
- "CAVORT"
- "UNCERTAIN"
- "BEWARE"
sarge -- alternatives to "TESTING":
- "SOON"
- "NEARLY"
- "UPCOMING"
- "ALMOST"
- "NOT YET"
woody -- alternatives to "STABLE":
- "SOLID"
- "DEPENDABLE"
- "READY"
- "SERIOUS"
- "STABLE" (heck, what could be more precise? :)
think of names that might help the debian-uninitiated grok a tad
more quickly the functionality and dependability of the release.
- wanna go play with the latest ready-to-break stuff? try
the "DANGEROUS" release (ooh, sounds sexy, doesn't it?)
and take your chances.
- want reasonably current stuff that hasn't been thoroughly
proven? install the "ALMOST" release.
- can't stand the thought of downtime? stick with "STABLE"
and expect it to deliver 700+ days uptime without breaking
a sweat.
the idea would be to pick names that will make (appropriate)
sense to people who are NOT intimately invovled in the project.
by all means, keep the fun code names (slink, potato, woody,
sarge, sid...) behind-the-scenes, of course. :)
after brainstorming, of course, consideration of multilingual
translations would be important; also, beware of terms easily
warped into derogatory forms by "enemy camps" (think "marketing"
and "spin"). but first, we need to gather all ideas, even ones
that may seem silly.
comments welcome.
=====
at serensoft part of our service -- after implementing a
reporting solution, typically -- is that we offer branded
documentation where we provide the clientele with three layers
of printed "help/manual":
"beginnings" -- gentle step-by-step for simple newbie tasks
"foundation" -- reference-like, showing 80% of all they'll need
"horizons" -- show off advanced features, pique their interest
the naming system for debian releases could be like this. when
we finalized our documentation name branding scheme (after much
trepidation) both the doc writers and the clients registered
better understanding of what was expected to be in each layer.
proper branding can really line up the perception with the
reality when your terms are cleverly chosen. and you have a lot
less explaining to do when first-timers quickly "get it" at
first glance.
=====
okay, i admit it, i've got an ulterior motive: i'd love to see a
debian box in every basement and on every office desk. (i've got
two of each in my own house, of course.)
and i think the best way to see that happen is to make it easier
for joe average to 1) find out about the advantages of debian by
2) trying it out and having it work. a friendly installer, a
naming scheme that gets him to download the appropriate (i.e.
less likely to be disappointing) release, readable howtos that
are germaine to what he's interested in accomplishing with it,
and so forth.
this means departing from "we created it, and we understand it,
so becky had better learn to think the way we do" and moving
toward "what does becky expect, and how can we communicate to
her that she can do all that and more using debian?"
debian is a great implementation of an awesome idea. let's
fertilize the garden and see what happens.
--
I use Debian/GNU Linux version 3.0;
Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown
DEBIAN NEWBIE TIP #90 from Der.Hans <[EMAIL PROTECTED]>
and Joey Hess <[EMAIL PROTECTED]>
:
Wondering HOW TO GET CPAN MODULES FOR PERL?
man CPAN
Not too many manpages need capital letters. (It's a Perl module
that comes with Perl, or at least has since Potato or before.)
Then,
perl -MCPAN -e 'shell'
CAVEAT: if the Perl module is not packaged in *.deb Debian
format (and about 270 are), the next best thing is to use the
dh-make-perl, which can build debian packages on the fly out of
CPAN.
Also see http://newbieDoc.sourceForge.net/ ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
