On Sun, 24 Oct 1999, Lalo Martins wrote: > On Mon, Oct 25, 1999 at 01:39:23AM +0200, Gergely Madarasz wrote: > > On Sun, 24 Oct 1999, Lalo Martins wrote: > > > > > Implementation: > > > > > > When the current Unstable (potato) is frozen, instead of > > > creating a new Unstable area, we will create the Pool and > > > populate it with a copy of potato; plus, create an empty Working > > > area and wait for maintainers to start populating it; plus, > > > > Hm... this is an oversight, I believe. The new working area should be > > populated by symlinks to the latest stable/frozen... > > I don't think so. Let the maintainers decide what is > ``working''. If they think that's the version in ``stable'', > then they can easily make things that way.
If something is in stable, then it is ``working'' by current definition. If nothing else is declared ``working'' then the stable version should be there. > > > delete the "project/experimental" area. Of course the promotion > > > automating software must be working and tested by then. > > > > I'm not quite sure about the need to remove the project/experimental > > area... The working area wouldn't be updated quite as often as unstable is > > currently, so I'd probably use apt on the pool... and I wouldn't want to > > use apt on some software from the current project/experimental... > > (For example I'd gladly follow the current NMU series of dpkg, while I'm > > not so sure about the dpkg in project/experimental yet) > > Read the proposal again. What you said just defeats the whole > point. I thought the point of the proposal was to have better release management, with better tested packages, etc... read later... > You're not _supposed_ to run apt on pool unless you're > willing to live on the edge. It would be equivalent to running > apt on experimental. > > Perhaps we can implement the long-promised feature of apt to > let the user choose one of many installable versions, so you > _can_ run apt on pool and choose the version of your liking. > But that's an entirely different point. > > In simple words: if you want safe stuff, ``working''. If you're > willing to run risks, ``pool''. Period. There is a big difference between the risks of current unstable and current project/experimental. As I said, I'm willing to take the risks of the first, and I'm not willik to take the risks of the second. I expect that the ``working'' set will be much more stable than current unstable. Now lets take this: how does the maintainer decide if a package in the ``pool'' can be promoted ? If there are lots of people who tested it... I (and probably lots of others) wouldn't test it because the risks here are higher then in current unstable. So how does it get tested well ? Please explain the situation with the current dpkg packages in unstable and project experimental. Remember, I want the latest from the NMU series, and I don't want dpkg 1.5.x yet. Greg
