[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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: