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
