Date: Mon, 18 Dec 2000 19:14:42 +0000 From: Nik Clayton <nik@freebsd.org> To: "Bruce A. Mah" <bmah@FreeBSD.ORG> Cc: jim@osd.bsdi.com, doc@FreeBSD.ORG Subject: Re: Supported hardware list(s) Message-ID: <20001218191442.A11618@canyon.nothing-going-on.org> In-Reply-To: <200012181741.eBIHfjt94333@bmah-freebsd-0.cisco.com>; from bmah@FreeBSD.ORG on Mon, Dec 18, 2000 at 09:41:45AM -0800 References: <20001215133609.A23331@envy.geekhouse.net> <200012181741.eBIHfjt94333@bmah-freebsd-0.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 18, 2000 at 09:41:45AM -0800, Bruce A. Mah wrote:
> First, there are actually six different places where we list hardware:
> The install chapter in the handbook, the appendix in the handboox, src/
> release/texts/HARDWARE.TXT, src/release/texts/i386/RELNOTES.TXT, src/
> release/texts/alpha/ RELNOTES.TXT, and src/release/texts/alpha/
> HARDWARE.TXT. The "generic" HARDWARE.TXT and the platform-specific
> RELNOTES.TXT files are probably the two that get updated the most
> frequently; the alpha-specific HARDWARE.TXT file deals with which alpha
> hardware platforms we can run on. Note that some of these files are
> even organized differently (i.e. section headers, etc.). It's ugly, and
> I'll freely assume my share of the blame for making it so.
>
> > Here's what I propose:
> >
> > 1) Nuke the hardware compatibility appendix. It's quite out of date,
> > and since no one has taken an interest in "claiming" it as their
> > own, we should get rid of it.
>
> Well, it's out of date, but at least on first glimpse, it appears to
> have some useful information that isn't found anywhere else in our
> documentation.
Interesting info, but we need to do some copyright cleanup on it. In
particular, we need to go back to the original authors for everything
that's got a copyright statement, and either get their permission to
relicense it, or yank it.
[ IMHO -- I don't really want to get in to a licensing discussion, but I
do think that the doc/ tree should be under the two clause license. ]
> > I'm interested in hearing what others think -- I know there are a lot of
> > folks who'd like to see one hardware list, and I'm one of them :-)
> > Comments?
>
> I think the end goal is a good one. I was working on this issue from a
> slightly different angle. I talked with a few people at BSDCon about
> the subject of fixing up the *.TXT files, specifically, doing them up in
> DocBook. The goal of this exercise would be to produce a smaller set of
> files for the release notes (e.g. one file total, not one per platform)
> and hardware lists which is customized when output is generated to apply
> to different plaforms. Also, we could do "better looking" release notes
> in PDF, PS, HTML, TXT, and so forth, possibly with some help from the
> stylesheet gurus amongst us.
Also, we can do this
http://www.BSDI.COM/products/internet/hardware/
(web based interactive hardware database).
> I got some weak agreement to this idea, then I went off and did some
> DocBook coding, and then got bogged down in Real Work (TM). (Note: I'm
> still in that mode.) I've put a snapshot of my work at:
>
> http://people.freebsd.org/~bmah/relnotes.tar.gz
Looks like a good start.
> I still haven't figured out the ramifications for the release-building
> process yet; it looks like this makes having release notes dependent on
> both a doc tree plus the DocBook toolchain.
True.
> Someone (dougb?) suggested
> putting a placeholder RELNOTES.TXT in src/ release/texts/${arch} that
> gets overwritten by the "real" release notes if we actually generate
> them.
Also a good idea.
> Other things I'm stalled on: Lack of time (of course), and experience
> at doing the SGML markup. Also the myriads of hardware info lists would
> need to be consolidated. Finally, the doc tree as it stands is not
> branched (a la CVS), but putting release notes in the doc tree would
> mandate it. (Putting it in the src tree doesn't automatically solve
> the problem, because I think there's some dependencies on some files,
> such as style sheets or entity definitions, that only live in the doc
> tree.)
I don't really want to see the doc/ tree branched. However, the
osversion* attributes should let us support this, and I have some
experimental support for this working right now. I'll send a separate
message out for that. Then there's no need to branch.
> So...if we got this to work, one thing the handbook *could* do would be
> just to include some version of this file. But on the other hand, maybe
> it could just point to the end product of this thing I've been tinkering
> with.
I don't think it matters too much whether or not the Handbook includes
it or links to it. As long as it's all available in one place.
N
--
Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95.
Telephone line, $24.95 a month. Software, free. USENET transmission,
hundreds if not thousands of dollars. Thinking before posting, priceless.
Somethings in life you can't buy. For everything else, there's MasterCard.
-- Graham Reed, in the Scary Devil Monastery
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001218191442.A11618>