From owner-freebsd-current Thu Apr 26 9:58:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by hub.freebsd.org (Postfix) with ESMTP id 47FFB37B423; Thu, 26 Apr 2001 09:58:44 -0700 (PDT) (envelope-from bmah@cisco.com) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA14842; Thu, 26 Apr 2001 09:59:10 -0700 (PDT) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.3/8.11.1) id f3QGwhs37643; Thu, 26 Apr 2001 09:58:43 -0700 (PDT) (envelope-from bmah) Message-Id: <200104261658.f3QGwhs37643@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4 To: Nik Clayton Cc: "Bruce A. Mah" , freebsd-current@freebsd.org, freebsd-doc@freebsd.org Subject: Re: [RFC] RELNOTESng for 5-CURRENT In-Reply-To: <20010426103003.A52781@canyon.nothing-going-on.org> References: <200104241603.f3OG3AB06290@bmah-freebsd-0.cisco.com> <20010426103003.A52781@canyon.nothing-going-on.org> Comments: In-reply-to Nik Clayton message dated "Thu, 26 Apr 2001 10:30:04 +0100." From: bmah@freebsd.org (Bruce A. Mah) Reply-To: bmah@freebsd.org X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1438040942P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 26 Apr 2001 09:58:43 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --==_Exmh_1438040942P Content-Type: text/plain; charset=us-ascii 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. --==_Exmh_1438040942P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE66FPD2MoxcVugUsMRAmcgAKD+BObfxPVUDIzwyhN1f3WFAMr9WQCeON74 MOVjuSSfyUm6A3FTRC0WZCw= =/hdu -----END PGP SIGNATURE----- --==_Exmh_1438040942P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message