Re: Proposal: incremental release process (the package pool)
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
Reply to: