Date: Sun, 29 May 2005 10:50:17 -0700 From: "Bruce A. Mah" <bmah@freebsd.org> To: Hiroki Sato <hrs@freebsd.org> Cc: bmah@freebsd.org, cvs-doc@freebsd.org, PeterJeremy@optushome.com.au, cvs-all@freebsd.org, simon@freebsd.org, doc-committers@freebsd.org Subject: Re: cvs commit: www/en/releases/5.4R errata.html Message-ID: <1117389017.762.21.camel@localhost> In-Reply-To: <20050530.002750.74719916.hrs@allbsd.org> References: <1117258487.764.14.camel@localhost> <20050528082910.GH787@zaphod.nitro.dk> <1117298991.46625.33.camel@tomcat.kitchenlab.org> <20050530.002750.74719916.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-30PAQJfR4UcJaZaKd+ke Content-Type: text/plain Content-Transfer-Encoding: quoted-printable If memory serves me right, Hiroki Sato wrote: > Hi, sorry for my being inactive recently. I was very busy this month but > I finally have the time... Believe me I'm familiar with that situation... :-p > "Bruce A. Mah" <bmah@freebsd.org> wrote > in <1117298991.46625.33.camel@tomcat.kitchenlab.org>: >=20 > bm> OK. How about something like the following paragraph and table (pret= end > bm> there is some real DocBook markup in here and don't worry too much ab= out > bm> the wording): >=20 > I like this idea. Thanks. I don't know why we (collectively) didn't think of this earlier. > bm> A related point: The errata document for (for example) 5.3 was > bm> maintained on the RELENG_5 branch (and not RELENG_5_3). So right bef= ore > bm> we branched for 5.4, the 5.3 errata content was purged. Thus, users > bm> tracking the 5.3 security fix branch can't count on the errata docume= nt > bm> being current anymore; they have to go to RELENG_5_3 src/UPDATING to = get > bm> this information. (It's worked this way all the way back to > bm> 4.3-RELEASE. Curiously, nobody has complained to me about it in the > bm> past four years. I can't remember why I set it up this way.) >=20 > Hmm, for this problem I am thinking about using XML databases for > errata document. Probably we can agree that we should maintain > errata document for a release until its EoL, and duplicated > effort should be reduced. For security advisories, VuXML or > similar one can be used to put information into the errata page, and > by using XSLT, we can easily handle MD/MI separation and output > style change. With these databases the errata page can be generated > on-the-fly and trimming old items is not always needed. > The current structure limits reuse of information, so some sort of > improvements are needed. >=20 > I made several specific implementations and am still wondering > where we should put such databases. Anyway, I am planning to change > these framework before 6.0R (I will submit the necessary changes > to the public mailing-lists for review, of course). Hmmm. I'm still deciding how much I like this idea, but it sounds pretty interesting (and I mean that in a positive way). One concern I have about this approach is because we'd have a single database for all of the errata information, it probably cannot be branched in the same way that src/ is branched. So in effect it needs to track the existence of new branches separately. A reasonable counter-argument is that new branches don't happen very often (a few times each year) and that the benefits are worth the overhead of manually tracking the branching. I'd make the argument that this data should live somewhere in doc/ because: 1) A checked-out copy of doc/ is already necessary to build the release documentation anyway. 2) Files in doc/ are already used for multiple release/development branches (e.g. man-refs.ent and the build infrastructure), and it has roughly the same relationship with the release branches that one would want for these. Looking forward to seeing more of this idea... Thanks! Bruce. --=-30PAQJfR4UcJaZaKd+ke Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCmgDZ2MoxcVugUsMRAiH5AKCXJHnWv/7JVLpvosZX+SoTq+2b8wCdEcoH 0aJnHFRnlHjXP+Qm9Z/DqBk= =gEOJ -----END PGP SIGNATURE----- --=-30PAQJfR4UcJaZaKd+ke--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1117389017.762.21.camel>