Subject: Re: Proposition for Releases page changes
To: None <netbsd-users@netbsd.org>
From: Lasse =?ISO-8859-1?Q?Hiller=F8e?= Petersen <lhp@toft-hp.dk>
List: netbsd-users
Date: 03/31/2007 10:35:01
P.P. wrote:
>BTW. The more I read the documentation which is responsible for
>the first impressions the NetBSD website visitors may acquire, the
>more I think it needs changes. I'm going to write about it to www
>maintainers via "Contact us" service (feedback). What I think is that
>NetBSD release 4.0 could be associated with some changes in WWW pages.
>I'll present my suggestions here soon as well.

and inspired me to write the following rant, for which I hope to be pardoned.

Back in December, I asked for help about a font problem I was having with
XFCE4 window titles. Jeremy Reed answered most kindly, but as it was, I
didn't find a solution to my problem. (As it was mainly cosmetic, I didn't
look into it too hard.) A few weeks ago I think I stumbled upon someone
mentioning fc-cache on one of the netbsd lists. A hunch led me to try run
fc-cache -f and lo! it fixed the font problems I had! I then tried to look
into the NetBSD documentation to see if I could find an introduction to
fonts on NetBSD (seeing how this would have to deal with XFree86 and XOrg,
pkgsrc etc), mostly because I was confused by having both a
/usr/X11R6/bin/fc-cache and another one in /usr/pkg/bin, but also because
it was obvious that I knew far too little about the matter in general.

Anyway, you want to know what on earth this has to with this thread. Well,
I looked at the "NetBSD Documentation: The X Window System". The entry in
the table of contents saying: "X is very slow when compiling under NetBSD
1.3.x" confused my mind to a complete halt: "Okay, that may be have been
true at some point. But is it still? And more importantly, is it still
relevant? 1.3 came out nine years ago, and all of 1.x is unsupported
today. What's going on? If that part of the NetBSD X documentation is
associated with 1.3, how about the rest?"

This speaks to me in a very loud voice, that perhaps there are other parts
of this documentation that is dated - and possibly outdated. So I get
worried about what of it I can trust to still apply to the system I am
running. Yet, I am obviously not in a position where I can submit diffs
to suggest actual fixes.

Actually, I have used NetBSD since 1.3.something, and since 2.0 it has been
on the laptop which I use for everything (instead of a desktop workstation),
in addition to my personal server. I am sorry if I still come across as
ignorant sometimes, but I *am* first and foremost a user. I read about things
like Xen and ACPI, and I would love to start using them. I have used native
browsers with native Java, with lots of success, but also some problems.
NetBSD can be made into a terrific desktop/laptop system even with the little
effort I am capable of.

Back when I started using NetBSD, one of the things that impressed me was
the quality of the documentation. Today, I have problems finding my way
around. Definitely this must also be the case for new users. If the
NetBSD community wants to have more NetBSD users, while avoiding floods
of stupid questions on the lists, it would be a good idea to put some
effort into improving the documentation. Therefore, P.P. is right on
target when he suggests changes.

We don't need a dumbed down NetBSD for desktop users. What we need is
better documentation of how to customise a NetBSD+pkgsrc installation to
make a good desktop system. Or a good Mail/Web/Database/File server. Or a
good laptop system. Or a good virtualization system. And so on. I think
this could be a(nother) place where NetBSD could distinguish itself from
other systems. 

I don't know how this can be achieved. As Thor Lancelot Simon has pointed
out in a different thread, it is important that the official NetBSD
documentation is of consistent quality and carefully checked. This means
that any user contributions will have to be reviewed and edited by people
who can ensure this.

I have been thinking for some time about whether I could set up a machine
with Xen, running WindowsXP, NetBSD and Linux, and perhaps also some
TV-tuner hardware. I have hesitated, because I know I will not succeed
without help. Lots of help. But if I could have a "free pass" for asking
the experts about all the "stupid" problems that will pop up, in return for
a commitment to produce a detailed report about my experience, including a
step-by-step how-to, I might consider it an interesting challenge. The
report could then be reviewed by the "tutor" developers before being
published on the NetBSD website, probably in a special "User Report" or
"NetBSD Best Practices" section.

That was one idea to produce possibly useful new docs. Here's another idea,
for improving what we have: There has been some very successful "bugathons",
that have benefited the code. How about a "docathon", that could do the same
with focus on the documentation?

In more general terms, I think what I would like to know is this: how can I
- as a user - contribute usefully to the NetBSD project, without becoming a
developer or simply donating money? Maybe we should have some sort of NetBSD
User Manifesto, not a full-blown contract by any means, but an informal
guideline supporting the relations between NetBSD users and the NetBSD
project/foundation/developers to the benefit of all.

Such a manifesto could also ease the latent conflict I perceive in another
thread: "When NetBSD 4.0?", where I see P. P. wrote on March 21: "And me,
as user, have the rights to ask and to demand." A sentiment I understand
and maybe even share to a degree, although I also understand perfectly why
voluntary developers would disagree strongly, even to the point of reacting
to such a brash statement by resigning from a project.

A Manifesto could explain the benefits of the way NetBSD releases are made,
and offer some form of compromise, like perhaps:

    NetBSD releases are released when they are ready. As it is hard
    to know when a release is ready, right up to the time when it is,
    fixed release dates cannot be set and published. However,
    estimated schedules are posted when a release is branched, and
    when significant delays become known, the estimates are revised
    and reposted. You may consider whether your need for new features
    outweigh the risks of running NetBSD-current.

As far as I can tell, the above paragraph expresses the actual way things
are, yet putting it up front might reduce the eternal "NetBSD N - When?"
debates. I have seen it repeated in many variants on the lists, but I
don't seem to find it in the release-map page, where it might have a good
place, if we don't create a User Manifesto. For those who think that this
will just be stating something obvious, I can only say that evidence seems
to support the point that sometimes the obvious obviously needs to be
stated. Even when it is "well known" to apply to most Open Source software,
and not just NetBSD.

Am I saying something useful, or just making a fool of myself here? I don't
know - please tell me what you think.

Oh, I almost forgot that a vote on a proposal was requested by P.P.
+1 because I think the page in question can be improved
-1 because I think P.P.'s proposed version doesn't improve it by much.
So all in all, I abstain. :-)

-Lasse