Re: When a release is ready. (was Re: Re: Debian has turned unusable.)

2004-04-15 Thread Will Trillich
On Mon, Apr 12, 2004 at 10:46:46PM -0400, Jaldhar H. Vyas wrote:
 On Mon, 12 Apr 2004, Chris Metzler wrote:
  One thing that I've never understood, and haven't figured out by
  reading the Debian Reference or by osmosis from posts here (probably
  the Debian Developer documents is where I *should* look) is how the
  goals for a release are determined and communicated to anyone
  interested.
 
 If you find out can you let me know?
 
 I propose the Debian distributions be renamed to
 
 oozing
 settling
 congealed

delightful! not bad at all. memorable, clear, and with bountiful
character. very picturesque, and ought to help the newbies 'get
it'.

i know politics probably will reject these at the first filter
session, but it's got my vote!

:)

-- 
I use Debian/GNU Linux version 3.0;
Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown
 
DEBIAN NEWBIE TIP #129 from Paul Johnson [EMAIL PROTECTED]
:
Interested in HACKER CULTURE? For some fun browsing and
enlightening anecdotes, browse
http://ursine.dyndns.org/jargon/

Also see http://newbieDoc.sourceForge.net/ ...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: When a release is ready. (was Re: Re: Debian has turned unusable.)

2004-04-13 Thread Colin Watson
On Mon, Apr 12, 2004 at 08:47:59PM -0400, Chris Metzler wrote:
 So I would guess that there's some set of target properties that
 testing should have before it gets frozen that gets decided upon,
 e.g. the next release must include a 2.4 kernel by default with a
 2.6 kernel optional, the new installer, XF86 v4.3,  exim4, GNOME 2.2
 or higher, etc.  Whatever else is true about testing, and even if
 the release-critical bug count is zero, the release won't be made
 until these changes in the distro have been effected, since otherwise
 it isn't different enough or interesting enough to put out there as a
 new stable release.  And I wonder how those goals are chosen, and
 where one goes to find out what they are.  Probably an archive
 search of debian-devel would do it; but a better-publicized source
 (e.g. a page on the Debian website) might be a good idea.  If the
 user community had a clear idea what the major issues for each new
 release are, they'd know the particular packages/services to
 concentrate on playing with and filing good bug reports about and
 so on -- thus perhaps helping to speed up the release.
 
 I know that a major focus of this release is the new installer, and
 that right now that's the main thing people should focus on to help
 the release get out.  But earlier, I dunno what else I should have
 been installing and hammering on to help the release along.  I could
 probably find it in debian-devel's archives; but maybe a page off
 the Debian front page (Minimal Goals for the Next Release) would
 be a good idea.

Personally I'd rather see much more time-based releases once we've got a
reliably-updated installer post-sarge, but hey ...

The real reason that there's little in the way of information here is
that it could be reduced to a trivial page looking a bit like this:

   _ _   _ _
  |  ___(_)_ __ (_)___| |__
  | |_  | | '_ \| / __| '_ \
  |  _| | | | | | \__ \ | | |
  |_|   |_|_| |_|_|___/_| |_|
  
   _ _
  |_   _| |__   ___
| | | '_ \ / _ \
| | | | | |  __/
|_| |_| |_|\___|
  
   ___   __ _   _
  |_ _|_ __  ___| |_ __ _| | | ___ _ __| |
   | || '_ \/ __| __/ _` | | |/ _ \ '__| |
   | || | | \__ \ || (_| | | |  __/ |  |_|
  |___|_| |_|___/\__\__,_|_|_|\___|_|  (_)


Everything else is so far behind that goal that it isn't funny. It's
been in every release update posted to debian-devel-announce for the
last couple of years. There are minor bits and pieces, sure, but in
reality as soon as the new installer's really and truly ready for prime
time (which, finally, is a goal that's in sight) we'll be going straight
into freeze mode.

We (the release management team) have begun putting together better ways
to disseminate release targets, but I don't expect them to be decent
until we've got sarge out of the way.

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: When a release is ready. (was Re: Re: Debian has turned unusable.)

2004-04-13 Thread Paul Mackinney
Colin Watson declaimed:
_ _   _ _
   |  ___(_)_ __ (_)___| |__
   | |_  | | '_ \| / __| '_ \
   |  _| | | | | | \__ \ | | |
   |_|   |_|_| |_|_|___/_| |_|
   
_ _
   |_   _| |__   ___
 | | | '_ \ / _ \
 | | | | | |  __/
 |_| |_| |_|\___|
   
___   __ _   _
   |_ _|_ __  ___| |_ __ _| | | ___ _ __| |
| || '_ \/ __| __/ _` | | |/ _ \ '__| |
| || | | \__ \ || (_| | | |  __/ |  |_|
   |___|_| |_|___/\__\__,_|_|_|\___|_|  (_)
 
Colin, you've inspired me. I'm really happy running Sarge/Testing with
frequent apt-get dist-upgrades. The only gotcha I've hit in months was
the 2.6 kernel wonking my mouse in X and making cdrtoaster use a funny
device argument (still can't find the docs but a tip from this list got
me going). Of course, I'm happy with stodgy old Mozilla and run a bare
Blackbox config in preference to GNOME or KDE. And no, Hugo, I don't use
Mondo. I run a journalling file system (ext3) which I test by
using the power button to shut down. Haven't lost a file yet :-)

But what I haven't done is give back to Debian for years of free
computing. So I'm publicly comitting to downloading CDs, testing the
installer, and reporting bugs promptly. Specifically, next weekend I'll
spend up to 4 hours on it (not counting CD burning).

Regards, Paul

PS: Points off for the ASCII art, but your credit balance (based on many
excellent posts to this list) is not threatened :-)
-- 
Paul Mackinney
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



When a release is ready. (was Re: Re: Debian has turned unusable.)

2004-04-12 Thread Chris Metzler
On Mon, 12 Apr 2004 18:04:33 -0400
Derrick 'dman' Hudson [EMAIL PROTECTED] wrote:
 
 How about shortening the release cycle so that stable is more
 up-to-date?  Let's solve the problem rather than the symptons.  :-).
 
 (Note - this is not an invitation to begin a flamefest regarding why
 the release cycle is so long or to make suggestions regarding what
 other people can do to fix it.  Instead it is an invitation to first
 recognize the issue and second to help resolve it)

One thing that I've never understood, and haven't figured out by
reading the Debian Reference or by osmosis from posts here (probably
the Debian Developer documents is where I *should* look) is how the
goals for a release are determined and communicated to anyone
interested.

What I mean by goals can be illustrated by an absurd example.
Imagine that the day after sarge becomes stable, the testing
distribution is still exactly the same as sarge, except for a
revision update of some non-essential package (e.g. liferea or
frozen-bubble); that's all that's come down to testing.  This would
be a distro that could be released as stable; but it wouldn't be,
of course, because why issue another stable release when the only
difference is a slight change in some non-essential package?  I
know Debian's main threshhold for release is when it's ready;
but the new release has to be sufficiantly different from the
immediately previous one.

So I would guess that there's some set of target properties that
testing should have before it gets frozen that gets decided upon,
e.g. the next release must include a 2.4 kernel by default with a
2.6 kernel optional, the new installer, XF86 v4.3,  exim4, GNOME 2.2
or higher, etc.  Whatever else is true about testing, and even if
the release-critical bug count is zero, the release won't be made
until these changes in the distro have been effected, since otherwise
it isn't different enough or interesting enough to put out there as a
new stable release.  And I wonder how those goals are chosen, and
where one goes to find out what they are.  Probably an archive
search of debian-devel would do it; but a better-publicized source
(e.g. a page on the Debian website) might be a good idea.  If the
user community had a clear idea what the major issues for each new
release are, they'd know the particular packages/services to
concentrate on playing with and filing good bug reports about and
so on -- thus perhaps helping to speed up the release.

I know that a major focus of this release is the new installer, and
that right now that's the main thing people should focus on to help
the release get out.  But earlier, I dunno what else I should have
been installing and hammering on to help the release along.  I could
probably find it in debian-devel's archives; but maybe a page off
the Debian front page (Minimal Goals for the Next Release) would
be a good idea.

I dunno.

-c

-- 
Chris Metzler   [EMAIL PROTECTED]
(remove snip-me. to email)

As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear


pgp0.pgp
Description: PGP signature


Re: When a release is ready. (was Re: Re: Debian has turned unusable.)

2004-04-12 Thread Jaldhar H. Vyas
On Mon, 12 Apr 2004, Chris Metzler wrote:

 One thing that I've never understood, and haven't figured out by
 reading the Debian Reference or by osmosis from posts here (probably
 the Debian Developer documents is where I *should* look) is how the
 goals for a release are determined and communicated to anyone
 interested.


If you find out can you let me know?

I propose the Debian distributions be renamed to

oozing
settling
congealed

-- 
Jaldhar H. Vyas [EMAIL PROTECTED]
La Salle Debain - http://www.braincells.com/debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]