cvs commit: www/en/releases/5.4R errata.html

[Bruce A. Mah]

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 at freebsd.org> wrote
>   in <1117298991.46625.33.camel at tomcat.kitchenlab.org>:
> 
> bm> OK.  How about something like the following paragraph and table (pretend
> bm> there is some real DocBook markup in here and don't worry too much about
> bm> the wording):
> 
>  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 before
> 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 document
> 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.)
> 
>  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.
> 
>  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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-doc/attachments/20050529/d448c74f/attachment.bin