On Sat, Dec 19, 1998 at 09:02:28AM -0800, Oscar Levi wrote: > On Fri, Dec 18, 1998 at 03:15:44PM +1000, Anthony Towns wrote: > > [...] It's > > still Brian's decision when we've got enough libc6 packages done to > > say "Yup, that's good enough. Let's release." > And who is going to test this version? Let's say we do this. Let's > say that the unstable is the first stop for new packages. After some > time when 'we' decide that these work we put them into unstable. Who > is going to run prerelease Debian? If I run prerelease Debian, how is > that different from running the current unstable? Please read the proposals, much of this is explained in those. In brief, though: packages in the current unstable has one person running whatever tests are convenient for him/her to run on it. Ditto with frozen. This isn't enough for any sort of system that requires stability -- a lot of places just can't cope with X, or grep, or dselect, or apt not working. Minor bugs, sure, but having to play with ar and tar when dpkg starts segfaulting isn't an option. So the difference between the current unstable and frozen and the proposed prerelease is just that -- prerelease shouldn't have any bugs that make the system completely unusable. Basically the idea was to have the people who *can* cope with the occassional severe bug run unstable (ie, most of those who do currently), and packages wait for a couple of weeks (say) in unstable before moving to prerelease. That way if severe (read: release-critical) bugs get filed in those two weeks, the maintainer can fix the bug, and reupload without the various folks who follow prerelease suffering. Furthermore, I'm of the opinion that prerelease should have the appropriate tools available to make both CDs and bootdisks at regular stages (ie, every few weeks). I'm not sure how possible this is, unfortunately, but given anything of the sort, this enables the -testing group to test prerelease throughout the entire development cycle, which seems like a good thing to me. Essentially prerelease == unstable without the larger instabilities. > Now, this plan *does* make sense if we impose a testing framework on > top of prerelease. However, if we have a testing framework, there is > no reason to split unstable. We test packages before including them > in unstable and voila! we have new confidence in unstable. That's not really convenient. There are two places "before" unstable: Incoming and webspace. Incoming isn't mirrored particularly completely, and isn't apt'able. Webspace is difficult to find (you need to be on IRC and watching when someone shouts "hey, wanna test foobar.deb? http://xyz/!";. Neither have had the ftp masters check for broken .deb's, invalid PGP signatures and everything else. > > > Even without the libc5->libc6 migration, I don't think the proposal > > > has hands and feet. If we model each release as a 'product', then the > > > idea of migrating stable packages produces two debug phases. First in > > > the unstable and then in the stable. Just because a package works > > > among other unstable ones doesn't mean it will work in the stable > > > environment. > > This is a mischaracterisation of how unstable is intended to work. > > Since we would have three distributions: stable, prerelease and unstable, > > there isn't any longer a need to have every single package in unstable -- > > the ones that are in operational condition go in prerelease. > Right. How do we determine if a package is operational? By letting people install it, and file bugs. How did you think? Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. ``Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem.''
Attachment:
pgpdCX8PsUq6d.pgp
Description: PGP signature