On Tue, May 31, 2005 at 03:49:09PM +0200, Romain Francoise wrote:
Steve Langasek [EMAIL PROTECTED] writes:
In any case, given the number of prospective ports waiting in the
wings, 11 is probably a roughly correct estimate even if we *do* drop
some architectures.
Speaking of prospective
On 01/06/05, Pierre Habouzit [EMAIL PROTECTED] wrote:
IOW, it doesn't (directly) give meaningful predictions about the rate
at which a given piece of hardware becomes obsolete.
It also has no capacity to predict an organization's *ability* to
replace hardware.
ok, true
I'm aware
maybe the solution is to write a [EMAIL PROTECTED] (like [EMAIL PROTECTED]
or
[EMAIL PROTECTED] does) in order to ease the autobuilders :D (kidding of
course)
wouldn't that just be like DistCC that all the Gentoo users rave
about?
one can imagin a 'job' server that allow you to build
Andrew Suffield [EMAIL PROTECTED] writes:
On Tue, May 31, 2005 at 09:30:40PM +0100, Rich Walker wrote:
Andrew Suffield [EMAIL PROTECTED] writes:
Moore's law is cpu speed.
*TRANSISTORS* on a single die
http://www.intel.com/research/silicon/mooreslaw.htm
Bah, yeah, but it's more or
* Romain Francoise [EMAIL PROTECTED] [050531 15:49]:
Speaking of prospective ports, what would be the feasibility of keeping
testing frozen after sarge releases, do whatever toolchain updates are
needed to support amd64 via t-p-u, and release etch as a sarge+amd64
release in, say, 3 months?
Alexander Schmehl [EMAIL PROTECTED] writes:
http://www.nl.debian.org/vote/2004/vote_004
http://www.nl.debian.org/vote/2004/vote_003
I can hardly imagine, you can fix all that in three month.
Good point.
--
,''`.
: :' :Romain Francoise [EMAIL PROTECTED]
`. `'
Hamish Moffatt [EMAIL PROTECTED] writes:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
Wasn't the
On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
Hamish Moffatt [EMAIL PROTECTED] writes:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new
On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
Hamish Moffatt [EMAIL PROTECTED] writes:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk
On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote:
On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
Hamish Moffatt [EMAIL PROTECTED] writes:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark
On Tue, May 31, 2005 at 02:01:48PM +0200, Adrian Bunk wrote:
On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote:
On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
Hamish Moffatt [EMAIL
In any case, given the number of prospective ports waiting in the
wings, 11 is probably a roughly correct estimate even if we *do* drop
some architectures. (And since non-release ports are likely to stay
in unstable, and adding a release port adds three w-b databases where
dropping one only
On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote:
In any case, given the number of prospective ports waiting in the
wings, 11 is probably a roughly correct estimate even if we *do* drop
some architectures. (And since non-release ports are likely to stay
in unstable, and
Steve Langasek [EMAIL PROTECTED] writes:
In any case, given the number of prospective ports waiting in the
wings, 11 is probably a roughly correct estimate even if we *do* drop
some architectures.
Speaking of prospective ports, what would be the feasibility of keeping
testing frozen after
IOW, it doesn't (directly) give meaningful predictions about the rate
at which a given piece of hardware becomes obsolete.
It also has no capacity to predict an organization's *ability* to
replace hardware.
ok, true
I'm aware that more's law is not appliable on some archs (like arm
I
On Tue, 31 May 2005, Steve Langasek wrote:
Moore's Law governs the rate at which the speed of hardware (at a given
price-point) doubles. It says nothing about the speed at which current
software will *run* on current machines; and it certainly has nothing to say
about the speed at which such
On Tue, May 31, 2005 at 11:46:29AM -0500, Adam Heath wrote:
On Tue, 31 May 2005, Steve Langasek wrote:
Moore's Law governs the rate at which the speed of hardware (at a given
price-point) doubles. It says nothing about the speed at which current
software will *run* on current machines;
On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote:
In any case, given the number of prospective ports waiting in the
wings, 11 is probably a roughly correct estimate even if we *do* drop
some architectures. (And since non-release ports are likely to stay
in unstable, and
Andrew Suffield [EMAIL PROTECTED] writes:
Moore's law is cpu speed.
*TRANSISTORS* on a single die
http://www.intel.com/research/silicon/mooreslaw.htm
cheers, Rich.
--
rich walker | Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road |
need a
On Tue, May 31, 2005 at 09:30:40PM +0100, Rich Walker wrote:
Andrew Suffield [EMAIL PROTECTED] writes:
Moore's law is cpu speed.
*TRANSISTORS* on a single die
http://www.intel.com/research/silicon/mooreslaw.htm
Bah, yeah, but it's more or less the same thing for a given line of
chips,
* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [050531 08:58]:
Hamish Moffatt [EMAIL PROTECTED] writes:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
On Sun, May 22, 2005 at 08:10:35PM -0700, Steve Langasek wrote:
On Sun, May 22, 2005 at 12:46:09AM +0200, Adrian Bunk wrote:
As far as I understood it, the missing infrastructure for
testing-security was the reason why the release of sarge was delayed by
more than half a year.
As far
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
In this case, it did because of scalability issues. This was known and
publicised for quite a while; so either you're
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
Wasn't the infrastructure a prerequisite for woody and is working?
It turned out that the central part of the existing
On Mon, May 30, 2005 at 12:47:14PM +0200, Wouter Verhelst wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
In this case, it did because of scalability issues.
On 2005-05-21, Adrian Bunk [EMAIL PROTECTED] wrote:
Can anyone point me to an example where testing-security has actually
been used?
http://lists.debian.org/debian-security-announce/debian-security-announce-2005/msg00111.html
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
Wasn't the infrastructure a prerequisite for woody and
On Mon, May 30, 2005 at 10:48:38PM +1000, Hamish Moffatt wrote:
On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
It turned out that the central part of the existing infrastructure
didn't scale up well enough to cope with the new architectures in sarge.
There are no new
On Sun, May 22, 2005 at 12:46:09AM +0200, Adrian Bunk wrote:
As far as I understood it, the missing infrastructure for
testing-security was the reason why the release of sarge was delayed by
more than half a year.
As far as I have seen, it seems most security updates go either through
As far as I understood it, the missing infrastructure for
testing-security was the reason why the release of sarge was delayed by
more than half a year.
As far as I have seen, it seems most security updates go either through
unstable or through testing-proposed-updates.
Can anyone point me to
30 matches
Mail list logo
