Re: 1. RFD: Reorganization of the Debian Project

[stevegr@neosoft.com (Vociferous Mole)]

[This started as a short reply to Chris, and developed into
a long boring ramble. You have been warned.]

I've been reading these threads, and my first thought was "Yeah,
why are we so hung up on releases: we've got incremental upgrades",
but I wasn't really comfortable with it, and Lars clarified (for
me, at least) why releases *are* important.

I think that it is important that the stable tree be our best effort
at "install this, it will work". But that means that stable *isn't*
property of a package -- it's a property of the entire tree. Thus,
if you're going to move packages into the tree, they have to work
with whatever is there.

But that means, I believe, you can't make revolutionary improvements,
because when you make a big change (a.out to elf, for example, or
say BSD init to sys V init (or whatever the appropriate names are)),
you are going to break stuff. A lot of packages have to be changed.
They have to cooperate. And because we are a distributed developement
effort, it's not going to happen all at once. Some of us are going
to mess it up the first time, because we didn't understand the
requirements, or missed an important test case, or were just tired.

Yes, you can require that all changes be backward compatible. That's
a *lot* of work. It also means that every developer needs two
complete systems -- one for the "where we are going system",
and one for "where we were". I think it's better the way it
is -- stable works, and  unstable may  not. Periodically, we
say we're close, and declare a frozen and a new unstable. After
testing and bug fixes, we move frozen to stable.

Are there things that can be improved? Sure. For one thing, I think
the idea of multiple copies of packages in unstable would be a good
idea. Maybe the previous versions ought to hang around for 3 days,
or a week? That would make it easier to recover after you upgrade to
the latest version of xxx, which turns out to be a botch, without
having to keep old versions of every package. Additionaly,
I think we really need to split contrib and non-free into
stable and unstable.

Another idea, which may be a bit much, is to *not* create
unstable after creating frozen. Instead, everybody should be
concentrating on making frozen correct. After El Presidente (or
whoever) decides that frozen is releasable, then people can go
back to doing fun stuff. 

I think most of our agony over releases has been because we are
still changing the target right up to the last bitter moment. We
need to layout the goals for 1.3 *now*, set the date (april 1?),
and then do it. No additional goals starting march 15. Any new
ideas, no matter how good, are automatically in 1.4 or later. Maybe
this implies a third hierarchy? Fine. Maybe a developer only
heirarchy, either un-mirrored or selectively mirrored? I think
that 100+ developer's are probably enough to get from "nifty idea"
to "it should be in the next release". 

Absent a security bug, I think that being to the first distribution
to have version xxx of yyy is probably not sufficient reason to
hold up a release. This is a place where we can use the incremental
upgrade to our advantage. Also, many people care more about "works"
than "first".

Steve "and the longer it got, the more it rambled" Greenland

-- 
The Mole - I think, therefore I scream 

			"Goldfish... what stupid animals.  Even Wayne Cody
			 stops eating before he bursts."
[Local Seattle comedian]


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com