Joseph Carter wrote:
> IMO, dist and a half is mostly fluff as far as press releases go. potato
> and a half would be a potato dist with a 2.4 kernel, possibly some new X
> stuff if it can be done and a new apache. It's still out of date potato
> otherwise. I want a REAL upgrade!
In the case of
"J.H.M. Dassen (Ray)" wrote:
>
> On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote:
> > try this hypothetical release method out:
> >
> > there are two trees. let's call them devel and production. debian saavy
> > folks (maintainers) run devel. new packages are uploaded to devel where
> >
On Wed, 15 Mar 2000, Bdale Garbee wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> > After reading this nice diskussion with all it's aspects, I want to
> > complete the mess and suggest a "distribution" called
> > e.g. "progressive" beetween stable(frozen) and unstable.
>
> I gather you h
Michael Stone wrote:
On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote:
> On Wed, 15 Mar 2000, Ed Szynaka wrote:
> > > How does this account for drastic changes to something
like libc that
> > > might take weeks or months to shake out?
>
> Build daemons could take care
In article <[EMAIL PROTECTED]> you wrote:
You know, the whole concept of 'a release' is orthogonal to the way I think
about Debian. We've been through that before, too, and I understand the
various reasons that it's important for us to "make a release" from time to
time... but I doubt any of my m
On Thu, Mar 16, 2000 at 11:02:31AM +1100, Craig Sanders wrote:
> ??? - packages auto moved to here after basic criteria met (e.g.
> in unstable for 2 weeks with no bug reports). can't remember
> what this stage was to be called.
i feel a need to write some more about
On Wed, Mar 15, 2000 at 09:35:16PM +0100, J.H.M. Dassen (Ray) wrote:
> On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote:
> > It wouldn't help with out and out buggy programs but at least it
> > would catch dependency problems.
>
> It would catch problems with the dependencies a package
On Wed, Mar 15, 2000 at 01:34:22PM -0500, Mark Mealman wrote:
> > First things first. Let's get potato released, and then get pools and
> > flavors implemented before we try to release woody.
>
> I'm all for that if you think the pools idea has any chance of being
> implented in our lifetime.
I
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote:
> Well say that there are 3 releases a year. That gives say 3 months for
> devel. With a freeze scheduled to start at the beginning of the 4th
> month and a stable release at the end of a month of freeze. I think
> that even the most dr
On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote:
> On Wed, 15 Mar 2000, Ed Szynaka wrote:
> > > How does this account for drastic changes to something like libc that
> > > might take weeks or months to shake out?
>
> Build daemons could take care of the 90% or so of packages that w
On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote:
> A possibly naive question: apt-get will refuse to install packages if
> their dependencies aren't met. Why can't dinstall do the same?
It could do so.
> It wouldn't help with out and out buggy programs but at least it would
> catc
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote:
> > On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote:
> > How does this account for drastic changes to something like libc that
> > might take weeks or months to shake out?
>
> Well say that there are 3 releases a year. That gi
On Wed, 15 Mar 2000, Ed Szynaka wrote:
> > > The problem that I see is that there is too much time between stable
> > > releases. I think that shorter and much more regular time periods
> > > between freezes is necessary. By fixing the number and date of freezes,
> > > with say three or four a y
On Wed, Mar 15, 2000 at 03:06:57PM -0500, Jaldhar H. Vyas wrote:
> On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote:
>
> > But it won't. This approach ignores the fact that "stability" is a property
> > of a release as a whole (the set of packages and their interdependencies,
> > ISOs, boot floppies
> On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote:
> > The problem that I see is that there is too much time between stable
> > releases. I think that shorter and much more regular time periods
> > between freezes is necessary. By fixing the number and date of freezes,
> > with say thr
On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote:
> But it won't. This approach ignores the fact that "stability" is a property
> of a release as a whole (the set of packages and their interdependencies,
> ISOs, boot floppies and the upgrade path from the previous release) rather
> than the sum of t
On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote:
> try this hypothetical release method out:
>
> there are two trees. let's call them devel and production. debian saavy
> folks (maintainers) run devel. new packages are uploaded to devel where
> they are tested extensivly. when a package
On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote:
> The problem that I see is that there is too much time between stable
> releases. I think that shorter and much more regular time periods
> between freezes is necessary. By fixing the number and date of freezes,
> with say three or four
I really don't think that a "progressive" branch is necessary. The
problems involved in keeping track of three branches at one time and
trying to keep version dependencies in order between branches would far
out weigh any benefit that would be created by such a branch. IMHO the
structure (stable,
Jacob Kuntz wrote:
> the production branch should always work. a system could be put in place
> where you could always get an iso image of the production branch that is
> recent to within a few days. i imagine that we would need to get pools in
> place before we could even attempt this. this type o
i have seen a lot of discussion about a distribution half way between stable
and unstable. on the surface that sounds like exactly what we need, but at
least one person pointed out that this is not the way to manage a project
with hundreds of developers working against hundreds of seperate releases
dea has any chance of being implented
in our lifetime.
A really simple way of handling a "progressive" distribution would be to mutate
"frozen".
After potato ships have frozen become thaw. Thaw would be unstable except there
is a lag time between .debs hitting unstable and migratin
In article <[EMAIL PROTECTED]> you wrote:
> After reading this nice diskussion with all it's aspects, I want to
> complete the mess and suggest a "distribution" called
> e.g. "progressive" beetween stable(frozen) and unstable.
I gather you haven't read the discussion of package pools in the archi
"Bernhard R. Link" wrote:
>
> After reading this nice diskussion with all it's aspects, I want to
> complete the mess and suggest a "distribution" called
> e.g. "progressive" beetween stable(frozen) and unstable.
>
> As I understood the problem, at the moment, only the stable
> distribution is ab
After reading this nice diskussion with all it's aspects, I want to
complete the mess and suggest a "distribution" called
e.g. "progressive" beetween stable(frozen) and unstable.
As I understood the problem, at the moment, only the stable
distribution is able to be distributed, while the unstabl
25 matches
Mail list logo
