On Wed, 2004-07-21 at 16:08 +0100, Stuart Herbert wrote: > Think of it this way. Good change information, like good QA, is something > that is part of the professional behaviour reasonably expected of a software > engineer. Someone else alluded to this, and I'd just like to reinforce the point: in terms of assessing the risk of a potential upgrade, some sense of what has changed is necessary. Unfortunately, the typical ChangeLog in portage is: 18 Feb 2004; David Holm db-4.2.52_p1.ebuild: Added to ~ppc. and *evolution-1.4.6 (22 Mar 2004) 22 Mar 2004; Alastair Tse evolution-1.4.6.ebuild: version bump the trouble is especially evident in the second example. What are the changes between evo 1.4.5 and evo 1.4.6? That, of course, is answered by the contents of the upstream ChangeLog, which there usually is one. In this case it is: http://developer.ximian.com/projects/evolution/release_notes/1.4.6.html Which is actually what I, in an enterprise deployment manager role, need to know about before I can make an upgrade decision. The stuff about arches being marked stable, etc, is, while internally important, not terribly interesting compared to this. It would be fantastic if we can find a way to include such information. After all, the developer doing the version bump (or better yet, the user making the bug report) probably at least had a look at the changes list, where ever it is to be found. That information should at least be hyperlinked, and, far better - (especially if we're switching to an XML format) included in Gentoo's ChangeLogs. Cheers, AfC -- Andrew Frederick Cowie OPERATIONAL DYNAMICS Operations Consultants and Infrastructure Engineers http://www.operationaldynamics.com/