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

Re: Social Contract GR's Affect on sarge

(followups to -boot)

Anthony Towns wrote:
> We avoid those problems by having separate distros -- either testing and
> unstable or frozen and unstable (or sometimes experimental) -- what are
> the problems with having a branch of d-i that's being beta'ed in testing,
> and one that's continuing to be developed in unstable?

For that to work you need to have some way of propigating udebs
peicemeal from unstable to testing. Of course the way the testing
scripts do it relies on well-defined versioned dependencies and
conflicts between packages, which we currently don't have for udebs. I'd
like to add them eventually, but there are technical problems with
overriding fields that d-i uses for its own purposes. Also, it's not as
if people upgrade d-i systems at runtime like they do Debian systems, so
it would be easy to miss adding relationships, and not find out until a
broken combination of udebs landed in testing.

Testing also relies on reasonable use of the bts to catch RC bugs; d-i
has the problem that most of our bug reports come in in the form of
installation reports from users, which lump together a whole pile of
issues, and have to be manually sorted before they could be any help for
such a thing. And assigning priorities to the bugs could be hard. And
we're not doing especially well at keeping on top of the BTS.

Also, we have plenty of objects in d-i that are not packages, and are
not readily tracked as packages, but which have relationships with udebs
that would also need to be tracked to make this practical. Does
propigating a given udeb to testing where it will be downloaded and used
by a netboot image built last week break that netboot image? It depends
on the set of udebs that were in it and their relationships to the new

What you suggest probably has other problems as well. For example, right
now we are branched exactly as you describe, as we work to get beta4 in
testing released. While d-i in testing is in a fair state, d-i in
unstable is completly broken right now on 4 architectures
(<E1BIBZF-0007gO-4M@haydn.debian.org>). We can fix unstable only by
uploading a half dozen udebs or so to it. We would not want those udebs
to go to beta4. We may need to push different changes to those same
udebs through unstable to testing if we find problems in beta4. I guess
this is a problem we're familiar with past releases of Debian too. The
workaround there is something like, put the package in experimental, but
that won't help here; d-i does not pull udebs from experiemental at
runtime. So development in unstable is stalled until we release beta4 in
testing. Do you have a solution to this?

> > The only point in making a beta release is if we have something that we
> > think might be a final release candidate, or that is a useful snapshot
> > to take to get more testing from our users. 
> The others are: to make it possible to install Debian on recent hardware,
> to make it possible to install testing, and to ensure that the new
> development whether in d-i or in regular debs hasn't made it obscenely
> difficult to fix d-i so we can do working installs again.

Some off the cuff numbers, for i386 only. I've installed d-i daily
builds every day for past month. They've worked ok least 95% of the
time. There has occasionally been minor, annoying breakage that was
easily worked around.

IMHO having d-i at a reasonably working state, such as it is in most of
the time in unstable -- a state that approximates how well unstable
works (might not work today, try again tomorrow) -- is good enough for
all of the things you listed. We're aiming for a higher state with the
betas, something closer to stable. I guess you want to see something in

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: