Re: link to devel/release_info
>>>>> "James" == James A Treacy <treacy@debian.org> writes:
James> The link to devel/release_notes has been deleted from the main
James> web page. devel/release_notes provides information that is
James> frequently requested; primarily what version of the kernel and
James> X are included in the next (or current if appropriate) release.
Actually, that page is flawed for even this purpose: the kernel used
is reported as 2.0.36. That is x86-specific and incorrect. For
instance, for Debian/Sparc on the Sun4u architecture, you *have* to
use 2.2.x (currently, 2.2.1). For m68k, they use 2.0.35.
The X version is part of the release notes. I could easily add the
default kernel version as well (I already have the data for all
platforms).
James> Although I understand the reasoning behind removing the link,
James> as the person who answers most of the mail sent to webmaster,
James> I'm not happy it. Perhaps the information mentioned above can
James> be added to the release notes under releases/stable.
Will do. Most of it is already there. Maybe I'll try to make it more
prominent.
James> There really is a bigger issue here. How do users easily find
James> out what is (will be) available in current (future) releases?
James> The release-notes available with 2.1 answer most of the FAQs,
James> but not all. What document should be used for distributing
James> information on an upcoming release? Should this document
James> contain information on long term goals? (almost certainly yes)
James> Finally the clincher: who will maintain this page?
I specifically added the release notes to the boot-floppies CVS area
so the "release team" (if it's ever formed) can have easy access to
it. Until then, Bob and I will maintain it.
James> I'd like to see something that is managed by the release
James> manager. They should have a grasp on both where Debian is and
James> where it is going. The release notes included with each release
James> can then be generated from the information on this page.
I think it should be managed by the release *team*. The actual
release manager (Guy or Brian, if he hasn't already left) will be too
busy to much with this document and track all the platforms.
I know the whole release team concept is still vapor, but still it's
the only viable alternative I can see.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: