Re: [RFC] RELNOTESng for 5-CURRENT
On Tue, Apr 24, 2001 at 09:03:10AM -0700, Bruce A. Mah wrote:
There's a snapshot of RELNOTESng for -CURRENT, updated irregularly,
at:
http://people.freebsd.org/~bmah/relnotes/
Like it.
My main concern is that this is in the src/ tree. As other people
have said this is going to complicate things for src/ folks who just
want up to date release notes, and for doc/ people who might not track
-stable or -current, but who want to work on the SGML side of things.
Also, if we want to put these on the website then it means that anyone
doing so will need to have checked out www/, doc/, and src/release/
trees.
Could this come under doc/, and either have a CVS branch for RELENG_4
for just the release notes directory hierarchy, or I could start work on
the osrel{min,max,in} attribute support code again. . .
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/
FreeBSD Documentation Project http://www.freebsd.org/docproj/
--- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 ---
PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Wilko Bulte wrote: On Wed, Apr 25, 2001 at 05:06:12PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writ es: : Hey whatever. Let's just keep a rendered TXT version where it always : (ie. in the src/release... cvs) was but keep the originial as a sgml : version in the doc tree. UPDATING will continue to be a flat file, or I will no longer maintain it. Right ;-) Form follows function I thought I responded to Warner's, er, strong statement of his position, earlier, but I'm not sure. So, for the record, I *have* no intention, and never *had* any intention of touching src/UPDATING, changing its format, or even gazing wistfully in its general direction. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Thu, Apr 26, 2001 at 09:58:43AM -0700, Bruce A. Mah wrote:
This problem (which I agree is valid) is not so much a problem as to
where the release notes live, but the fact that one needs to actually
build human-readable renderings of them. If people can't be bothered
to install the docproj port and the doc/ tree to get release notes
living in src/, putting the release notes in doc/ sure isn't going to
help. It's trivial to put the release notes for -RELEASE versions up
(the Web site does this already), and Dima thinks it's possible to do
this for -CURRENT too (and -STABLE if and when it's applicable).
I think this, as a whole, is a non-problem. It's trivial to script a
daily build of the release notes and mirror it to the FTP site (and/or
include it in the twice daily build of the web site).
Putting the release notes in doc/ means that the src/ committers (who I
just *barely* got now to make changes to the release notes) are going
to have to chase through parts of the doc/ hierarchy. I'm pretty sure
I'm going to lose the few converts I've won if I let people talk me
into this.
True, true.
Also, if we want to put these on the website then it means that anyone
doing so will need to have checked out www/, doc/, and src/release/
trees.
I got the impression that this would not be hard. They don't need to
have all of src/ checked out, and if enough people complain about it, we
can probably make another module which is just the RELNOTESng part of
src/release.
I think that would be a definite requirement. We could even make
release/ a top level directory, alongside src/, doc/, and ports/.
Could this come under doc/, and either have a CVS branch for RELENG_4
for just the release notes directory hierarchy, or I could start work on
the osrel{min,max,in} attribute support code again. . .
Can it come under doc/? Sure. Do I think it's the right thing? No.
I don't like the idea of having one part of doc/ branched and another
part not (especially when the part that's not branched lives higher in
the directory hierarchy).
I don't either (just because I suggest something doesn't mean I always
think it's the best way).
At the end of the day, you're the guy doing the work. . .
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/
FreeBSD Documentation Project http://www.freebsd.org/docproj/
--- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 ---
PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Nik Clayton wrote:
Like it.
OK, thanks, that's a good start...
My main concern is that this is in the src/ tree. As other people
have said this is going to complicate things for src/ folks who just
want up to date release notes,
This problem (which I agree is valid) is not so much a problem as to
where the release notes live, but the fact that one needs to actually
build human-readable renderings of them. If people can't be bothered
to install the docproj port and the doc/ tree to get release notes
living in src/, putting the release notes in doc/ sure isn't going to
help. It's trivial to put the release notes for -RELEASE versions up
(the Web site does this already), and Dima thinks it's possible to do
this for -CURRENT too (and -STABLE if and when it's applicable).
and for doc/ people who might not track
-stable or -current, but who want to work on the SGML side of things.
You don't need to track -STABLE or -CURRENT to work on the docs. I run
4-STABLE on all of my machines except one, yet I routinely use those
machines to handle commits to 5-CURRENT and 3-STABLE as well:
% cd ~bmah/FreeBSD/5-CURRENT
% cvs co release
% cd ~bmah/FreeBSD/4-STABLE
% cvs co -r RELENG_4 release
% cd ~bmah/FreeBSD/3-STABLE
% cvs co -r RELENG_3 release
Putting the release notes in doc/ means that the src/ committers (who I
just *barely* got now to make changes to the release notes) are going
to have to chase through parts of the doc/ hierarchy. I'm pretty sure
I'm going to lose the few converts I've won if I let people talk me
into this.
Also, if we want to put these on the website then it means that anyone
doing so will need to have checked out www/, doc/, and src/release/
trees.
I got the impression that this would not be hard. They don't need to
have all of src/ checked out, and if enough people complain about it, we
can probably make another module which is just the RELNOTESng part of
src/release.
Could this come under doc/, and either have a CVS branch for RELENG_4
for just the release notes directory hierarchy, or I could start work on
the osrel{min,max,in} attribute support code again. . .
Can it come under doc/? Sure. Do I think it's the right thing? No.
I don't like the idea of having one part of doc/ branched and another
part not (especially when the part that's not branched lives higher in
the directory hierarchy). So if I want to work on RELENG_4's release
notes, I need to checkout HEAD's doc/ and then check out the release
note's subtree with a RELENG_4 tag.
The osrel{min,max} attributes work to a point, but they presume that
there is a total ordering on version numbers. For -RELEASEs, this just
*might* be possible. But when there's multiple development tracks going
on in parallel (and release note items appear *between* releases), this
falls apart. How do you express the idea that the fix for the
vulnerability described by a security advisory is present in
3.5-STABLE-after-2001-04-06, 4.2-STABLE-after-2001-04-06, and
5.0-CURRENT-after-2001-04-06? CVS branches (for all their shortcomings)
handle this pretty well, without the need for complex stylesheet
customizations. Let's just use the right tool for the right job.
(BTW I do want to try to use what you've done with attributes to
implement the DocBook arch= attribute, to do better multi-platform
support.)
I appreciate all the solutions people have put forth, but I think
they're solving a non-problem. If I leave the release notes in src/
(which is where they've *been* all along, I might add), it's a more
natural fit because release notes are tied to CVS branches and releases
(tags) on those branches. They live closer in the filesystem hierarchy
and, more importantly, they get exactly the same branching behavior as
the rest of src/.
Thanks,
Bruce.
PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 05:06:12PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writes: : Hey whatever. Let's just keep a rendered TXT version where it always : (ie. in the src/release... cvs) was but keep the originial as a sgml : version in the doc tree. UPDATING will continue to be a flat file, or I will no longer maintain it. Right ;-) Form follows function -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Tue, 24 Apr 2001, Bruce A. Mah wrote: [...] There are two disadvantages to going this route. I think they're fairly minor: 1. Generating a set of release notes requires the DocBook toolchain to be built, as well as the doc/ subtree. Note that RELNOTESng will have absolutely no effect on the buildworld/installworld procedure. [...] defaulting to off. Once the bugs have been shaken out, I'll make RELNOTESng the default and stop maintaining the *.TXT files. Eventually, the *.TXT files will get removed. Perhaps the *.TXT files could be periodically regenerated to their current location to 1) avoid a POLA violation and 2) allow for at least some RELNOTES without needing DocBook and doc/ (even if they may be slightly out of date). Just an idea.. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). I second this. It is true that current.freebsd.org and much of do-it-yourself distributions are generated with 'NODOC=YES', since it needs much time and disk spaces to process doc.1 target (especially setting up a DocBook environment). Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). Just like current 'doc' distribution of 'NODOC=YES', it would be helpful that *.TXT files are in src/release. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
[Please keep me as one of the explicit recipients of this email. Thanks.] If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] It is true that current.freebsd.org and much of do-it-yourself distributions are generated with 'NODOC=YES', since it needs much time and disk spaces to process doc.1 target (especially setting up a DocBook environment). My first reaction is, is doing doc.1 *that* much of a problem? When I was testing, it didn't seem like building this consumed much time or disk space compared to the rest of the make release process (i.e. building world and several kernels). A checked-out doc/ is 37 MB. Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). I think the only recurring cost that people are going to have to do is to keep a reasonably current copy of doc/. Building the docproj port is a one-time operation. After that, it takes about 15 seconds of wallclock time on my workstation to build the TXT version of the release notes (note that you'll get the SGML sources automatically under src/ release/doc). Just like current 'doc' distribution of 'NODOC=YES', it would be helpful that *.TXT files are in src/release. Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Second, regen-ing needs to be done automatically. I'm not going to do it by hand. Third, let's assume that there's some interest in actually having different localized versions of the release notes (note that the infrastructure supports it). What language do we build for the *.TXT fallback files? Finally, there needs to be some boilerplate text on the fallback files to indicate the generation date of the fallback versions, and a pseudo-disclaimer that they may be out of date with respect to the actual state of the code. If we get the automatic generation problem solved, this one should be easy. Like I said, I'm weakly opposed to doing this, but I'm also quite willing to be swayed. Cheers, Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:58:40AM -0700, Bruce A. Mah wrote: [Please keep me as one of the explicit recipients of this email. Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). I think the only recurring cost that people are going to have to do is to keep a reasonably current copy of doc/. Building the docproj port is Reasonably current effectively means not current . Aka out of date. Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. If people think getting the Docbook infrastructure in place is too much work/time they should accustom themselves to reading the raw Docboot source files. Like I said, I'm weakly opposed to doing this, but I'm also quite willing to be swayed. Please don't be swayed.. ;) W/ -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Hey whatever. Let's just keep a rendered TXT version where it always (ie. in the src/release... cvs) was but keep the originial as a sgml version in the doc tree. Just like ports/INDEX. Only better. I think it is important to solve the duplication problem we have. It would be very sad to see a release go out with a wrong X.X-RELEASE header in the README.TXT file, has it almost happened, if I'm not mistaken. :) A. Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Wilko Bulte wrote: On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: As UPDATING may contain information nessecary to run make world, it can't b e built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. Just to clarify, RELNOTESng will not have any effect whatsoever on the way that /usr/src/UPDATING is maintained. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Bad idea.. RELNOTES, HARDWARE etc are things that should be up to date. Not 'a bit uptodate' or 'slightly outdated'. I really would not like to see the idea being bloated by going this route. As UPDATING may contain information nessecary to run make world, it can't be built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. Sorry. My parser just made a mistake by expanding etc in RELNOTES, HARDWARE etc Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writes: : Hey whatever. Let's just keep a rendered TXT version where it always : (ie. in the src/release... cvs) was but keep the originial as a sgml : version in the doc tree. UPDATING will continue to be a flat file, or I will no longer maintain it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
In message [EMAIL PROTECTED] Warner Losh writes: : In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writes: : : Hey whatever. Let's just keep a rendered TXT version where it always : : (ie. in the src/release... cvs) was but keep the originial as a sgml : : version in the doc tree. : : UPDATING will continue to be a flat file, or I will no longer maintain : it. I should also add but I don't think this proposal applies to UPDATING to the end of that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Dima Dorfman wrote: On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. Hi Dima-- No objections, but no plans right now either. Mostly because I don't know enough about the Web site build. Got any ideas? :-) I'm not sure if it will *solve* the problem, but at least it will allevitate it somewhat. And it's aesthetically more pleasing to me (if that counts for anything). Note that this is a fairly new capability...we currently don't have a link for -CURRENT or 4-STABLE release notes. There might be some issues with this although I can't think of any off-hand. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Yeah, it should be optional. The thing-that-generates-the-Web-pages would need the src/release/ module (somewhere in its filesystem, not necessarily in /usr/src/release), plus doc/. RELNOTESng doesn't need a complete src/. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
Bruce A. Mah [EMAIL PROTECTED] writes: If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. [ snip other good reasons not to regen and commit TXT files ] I agree completely. On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
Sorry for late reply. bmah My first reaction is, is doing doc.1 *that* much of a problem? When bmah I was testing, it didn't seem like building this consumed much time or bmah disk space compared to the rest of the make release process (i.e. bmah building world and several kernels). A checked-out doc/ is 37 MB. It takes long to fetch all distfiles for docproj ports. Sometimes they are updated. Sometimes they can't fetch. Sometimes text/docproj can't build (we can't build textproc/jade _now_, since PATCHFILES are already outdated, its path is old, and ftp.freesoftware.com is still offline :-) speaking of textproc/jade, it's easy to fix and I've already have a patch but not yet tested). For ordinally make-build/installworld users, how many people understands that they should install textproc/docproj _only_ for making their plaintext relnotes? Most of them don't need SGML-whatever converter for other situations. If installing textproc/docproj is essential for getting all documents in src/, it should not be a port (src/contrib will be their friends); if it's not essential, a port is ok. And in my opinion, relnotes are tightly associated with src/ components just like src/UPDATING. Hmm... Maybe all of my concerns is that getting relnotes (formatting is not a problem; plaintext will be easy, but I don't argue that the only version is PDF) without having some processing/compilation (installing some ports, type 'make' command, etc). If generating relnotes are _optional_ (Makefiles don't _enforce_ us to install textproc/docproj for all machines which run make buildworld or make release), it's ok if somebody's generated version (format is not the matter; plaintext, HTML, PDF, anything) of relnotes are avaliable via ftp, web, or any protocols of the Internet at any time. -- - Makoto `MAR' MATSUSHITA P.S.: I'm totally agree with RENOTESng system. It'll help to improve the project and the quality of document itself. But please keep some rooms for lazy guys (like me) who refuses to change their style :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[RFC] RELNOTESng for 5-CURRENT
(Apologies to -doc people who have probably heard this ad nauseum.) Over the past few months, I've been working on a project that I've taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and related files that we package along with a FreeBSD distribution. I've been soliciting feedback from the other -doc folks, and it's time to socialize this out to a wider audience. The main problem this is intended to solve is that there's a lot of information in many different files, and not all of its is consistent. For example, a list of hardware supported by FreeBSD can currently be found in four different places (the alpha and i386 RELNOTES.TXT files, HARDWARE.TXT, and the Handbook). What I've done is to reorganize and reformat all of the *.TXT files. The new versions of these files are done in DocBook/SGML, which is the markup language used for the Handbook, FAQ, and so on. This gives us several distinct advantages: 1. By using conditional inclusion of text, we can have one set of source files that contains platform-independent text plus text applicable to particular architectures (no more double commits for each new release note). Looking down the road, when we support other architectures (for example, ia64 or ppc), we'll have a scalable way of handling them. 2. By going to DocBook, we can produce release notes in formats other than plain ASCII text; for example, we can do HTML or PDF. We gain greater readability, plus we can take advantages of features such as hyperlinks within documents. Of course the boot floppies still get the TXT files. 3. By adopting the same naming conventions and directory structures as the doc/ subtree, we can support translations of release notes, if the translation teams are so inclined. 4. Reorganizing the *.TXT files elminates some redundant information and reduces the number of files that people have to read through (they're a bit longer, but better-organized). There are two disadvantages to going this route. I think they're fairly minor: 1. Generating a set of release notes requires the DocBook toolchain to be built, as well as the doc/ subtree. Note that RELNOTESng will have absolutely no effect on the buildworld/installworld procedure. 2. It raises the bar a bit for committers wanting to make changes to the release notes, since they'll need to make changes to the DocBook files. Barring objections, I want to commit RELNOTESng, plus a patch to src/ release/Makefile, to the CVS tree. RELNOTESng still needs a bit of testing, and so for now, I have it controlled by a make(1) flag defaulting to off. Once the bugs have been shaken out, I'll make RELNOTESng the default and stop maintaining the *.TXT files. Eventually, the *.TXT files will get removed. There's a snapshot of RELNOTESng for -CURRENT, updated irregularly, at: http://people.freebsd.org/~bmah/relnotes/ It contains PDF, HTML, and TXT versions of the various documents, as well as a tarball of my working sources, the patch for src/release/Makefile to integrate RELNOTESng into the release build, and an ISO of a 5.0-CURRENT, i386 release I did with RELNOTESng enabled. I'd very much like to get comments from people. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
* Bruce A. Mah [EMAIL PROTECTED] [010424 09:04] wrote: (Apologies to -doc people who have probably heard this ad nauseum.) Over the past few months, I've been working on a project that I've taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and related files that we package along with a FreeBSD distribution. I've been soliciting feedback from the other -doc folks, and it's time to socialize this out to a wider audience. The main problem this is intended to solve is that there's a lot of information in many different files, and not all of its is consistent. For example, a list of hardware supported by FreeBSD can currently be found in four different places (the alpha and i386 RELNOTES.TXT files, HARDWARE.TXT, and the Handbook). What I've done is to reorganize and reformat all of the *.TXT files. The new versions of these files are done in DocBook/SGML, which is the markup language used for the Handbook, FAQ, and so on. [snip] I'd very much like to get comments from people. Sounds like some excellent work that was long over due. Go for it. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Tue, Apr 24, 2001 at 09:25:34AM -0700, Alfred Perlstein wrote: Sounds like some excellent work that was long over due. Go for it. :) Agreed. I've always found there are doc hackers willing to help with markup problems on request, so I don't think that's a serious issue. Kris PGP signature
