(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 udeb. 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 between. -- see shy jo
Attachment:
signature.asc
Description: Digital signature