Date: Tue, 12 Jun 2001 13:24:23 -0400 From: "Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca> To: bmah@FreeBSD.ORG Cc: Kenneth W Cochran <kwc@world.std.com>, freebsd-stable@FreeBSD.ORG Subject: OT: rendered copies of RelnotesNG in the tree (was: RELNOTESng problems) Message-ID: <3B265047.4060605@lmc.ericsson.se> References: <200106121443.KAA18844@world.std.com> <3B2637CA.9050803@lmc.ericsson.se> <200106121629.f5CGTZF27955@bmah-freebsd-0.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce A. Mah wrote: > If memory serves me right, "Antoine Beaupre (LMC)" wrote: > >>IIRC, to build the relnotes now, you need to build a release, which is >>something I haven't had the resources (drive space and man-hours) to do >>since 2.2.6, which is when I discovered fbsd. :) > > You don't need to make a release. Please see the README file (which > you quoted below). Yes. I should have put a "see below" or something like that in there. I read the README only after writing this para. >>I totally agree with Kenneth here. >> >>I think that we should keep the rendered .TXT files in the cvs >>repository. Even if they're not exactly up to date, it's better than >>having nothing at all, or needing megabytes of third-party text >>processing code, just to have *text-only* release notes. > > How does the Web-available versions differ from putting the TXT > rendering in the repository? Not much. But one might like to consider the idea of having the TXT files *implicitly* available along the source code (bundled), instead of as a "foreign" reference on a website. I can see many situations where one could not have access to the web but only acces to the local machine which contains the source code. Another thing which crosses my mind: when someone installs a RELEASE, the relnotes TXT/rendered versions come with it and are installed as part of the install process, right? What happens when the system is updated (cvsup/make world)? Do these files stay where they are? Then they're obsolete and should be removed. > The Web versions will (once the Web > Gods make a couple of commits) get built as frequently as the Web site > is. That's about once a day, if I'm not mistaken? How technically feasable would it be to have the TXT files rebuilt on the fly, after a commit on the related .sgml file? > In the meantime, you can look at the version on my Web page. They're > updated pretty often, on an unofficial basis. Assuming I have access to the web. :) That is of course considered irrelevent nowadays, but I find that still a considerable requisite to have access to notes so tightly integrated (or relevant? I miss the proper word) to the source... These things should all be bundled together. >>Come on people, it can't be so hard to keep a copy of the rendered >>versions in the cvs? Asami does it for /usr/ports/INDEX, iirc. And no >>one complains if it's out of date. >> >>We just have to plaster a big WARNING in the readme saying that the >>files are not necessarly up to date... > > Release notes that are that far out of date aren't useful. Actually, the release notes are *implicitly* out of date, since we have no formal/automated system of updating the relnotes when a major change is made. AFAIK, there is someone (you, Bruce?:) that updates them by watching cvs-all, but that is also an out of date process. OTOH, putting the TXT files in the repository would also add to the delay. > (No slam intended on asami...I don't think we need an INDEX file that > tracks the ports collection as closely as we need release notes that > track the source. Especially not with origin-aware ports.) [OT]: Indeed. What's more, I don't really recall using the INDEX file at all, recently. ;) No slam intended on our mighty port wraith either. :) >>>Additionally, I "question" the necessity of requiring tools >>>"outside" the base-OS solely for reading the relevant release >>>notes/errata. >>> >> >>Again, I agree here. Having these release notes is a pretty good hint of >>what's new or MFC'd in current or stable. I often use it to tell myself >>running -current is a good thing. (joking) ;) >> > > If you depend on the release notes to know what's new, you'd want them > to be up-to-date wouldn't you? Yes. But I would also like them to be conveniently available as a reference, if not completely up-to-date. If I want them up-to-date, I go see the sgml files or the cvs logs of these, because the rendered versions are implicitly out of date. But again, don't get angry, because: >>I don't want to hit on anyone's head with this, and I think that the >>move to relnotesNG is a really good one, cleanly accomplished. > > Thanks. > >>I just think having the .txt files rendered is a really simple thing to >>do for Global User Satisfaction (tm). > > I'm not opposed to the idea of making the release notes more accessible > to people who can't (or don't want to) build the docproj tools. This > isn't a problem. That's why we put versions on the Web (granted it > could be a little better integrated, we're working on that). I just > don't see the point of bloating the repository with the rendered > versions. See above. The only point I have is that I miss my good old TXT files and browsing the web is a pita, for me, and for various reasons. Also, there is my point of having the stale -RELEASE relnotes and errata lying around that could be a major hassle... And you also have a pretty good point there about bloating the repository. :) I guess my point has probably been made by other people on -doc, so I'll shut up now. Anyways, this is getting completely off-topic for the list (my fault). A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B265047.4060605>