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
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 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
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
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 of
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 haven't read the
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
they are
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 unstable
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 able to be
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 archive?
in the archive?
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.
A really simple way of handling a progressive distribution would
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
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 of
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,
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 a
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 has
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 the
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
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 and the
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 year, and
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 gives say
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
catch
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 would
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
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
25 matches
Mail list logo
