Date: Wed, 29 Nov 2000 10:35:45 -0700 From: Mike Porter <mupi@mknet.org> To: freebsd-doc@freebsd.org Subject: Re: draft article, for review Message-ID: <00112910354501.11309@mukappa.home.com> In-Reply-To: <20001129144252.A23325@canyon.nothing-going-on.org> References: <p0500191eb6485fe68c33@[192.168.168.205]> <20001129144252.A23325@canyon.nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 29 Nov 2000, Nik Clayton wrote: As one of your "lurkers" (OK, so I'm rather new at this, and spend most of my time reading things....eventually I'm sure I will get around to saying something useful.....) (since I'm not on ScrollKeeper, I didn't put that in the list; feel free to forward it as you feel appropriate (just let me know if you did so)) > This is how the process works -- people find problems, fix them, and > submit patches. Sometimes the people finding the problem are already > committers, but a lot of the time it's FreeBSD users. And with the best > will in the world, a PR with a patch is a hell of a lot easier for a > committer to deal with than a message saying that something needs > fixing. > This is exactly the power behind Open Source Software, and why, eventually, it will win out over expensive commercial software, at least for a lot of(most?) things: It give the end-user Power over what happens. Don't like the way something works? great, fix it. Think something needs better docs? Great, let's sit down, bang--I mean, put--our heads together, and see what we can come up with. Sure, in a lot of cases, people don't (especially at first) have the knowledge to be able to put something together like that, or to write their own patch, but with some handholding, most people can learn. What a single person (or even a small group of people) can't do alone, when you have a group of thousands, it is a lot easier to get stuff fixed. Face it, there are a lot of documentation holes in the stuff coming out of Redmond these days, but when was the last time you heard about a user writing his own doucmentaton, and having it become part of the system? > [ For example, the fact that sysinstall doesn't know about the > new documentation packages yet -- I know this is a problem, as do > people following this mailing list. But unless someone else steps up > to the plate (anyone!) with patches, the problem's going to have to > wait until I've got the requisite 12 clear hours to sit down with the > sysinstall code and write the glue. ] > Just a suggestion, (and I don't know much about how sysinstall is written, so feel free to smack me upside the head if I am out of line), but wouldn't it make sense to make sysinstall sufficiently modular that all you have to do is provide it with a "table of contents" file from which to generate menus? (especially in the Docs section). This would greatly simplify the changing of things to reflect new packages, changes, or additions. Sort of like the ".ini" files scattred around any WinDoze hard drive ([Menu_Option]\n path/to/file1:installed/path/for/file1\n path/to/file2:/path/to/install/file2\n .... for all files related to Menu_Option); all you have to do is change a couple of lines in a text file (and even I can do that!) and the changes are there. I realize that changing sysinstall in this manner is a non-trivial task; but once changed (or once that part (ie, the docs section) is changed) it makes future revisions much easier. Since the assumption is that sysinstall will probably be around for a while, I would argue that long-term you will have a net savings of time. my $0.02 (or less..) worth mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjolPnIACgkQZ7GovTQbIm4tyACfbDVHYSbNzJkV/puK1rRntE+2 ecYAnihxdWzoy1Q8ZdMkkyUigbmZJqlD =T0m9 -----END PGP SIGNATURE----- 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?00112910354501.11309>