On Fri, 22 Apr 2005 13:58:31 -0400, Patrick Ouellette wrote:
> On Mon, Apr 18, 2005 at 04:24:34PM -0500, Adam M wrote:
>> In many ways, current testing is your stable. Extending the testing
>> period from testing to your proposed candidate and then stable would
>> do nothing about normal bugs. RC b
On Fri, Apr 22, 2005 at 02:54:38PM -0400, Patrick Ouellette wrote:
> On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote:
> >
> > The problem is that for many transitions, "slowly" means "never", since
> > the criteria you set are unlikely to be fulfilled for all parts of such
> > a tran
On Mon, Apr 18, 2005 at 04:24:34PM -0500, Adam M wrote:
> A similar thing is already here in http://snapshot.debian.net/
Similar only in that they have daily snapshots. Vastly dissimilar in
that what is provided is the complete archive, bugs and all.
I'm not saying we call each day a release, bu
On Fri, Apr 22, 2005 at 12:02:39PM -0400, Patrick Ouellette wrote:
> On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote:
> > Let my try to explain it:
> >
> >
> > The "debian stable == obsolete" is a release management problem of
> > Debian. One release every year and it would be suitab
On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote:
> Let my try to explain it:
>
>
> The "debian stable == obsolete" is a release management problem of
> Debian. One release every year and it would be suitable for most
> purposes.
>
This is the problem. Debian has NEVER been able to
On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote:
> The rules and goals of testing are clear.
>
> The more interesting points are the problems of testing that several
> years of using it have shown.
>
> > If package FOO has a RC bug, then everything that depends on FOO will be
> > stu
On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote:
>
> The problem is that for many transitions, "slowly" means "never", since
> the criteria you set are unlikely to be fulfilled for all parts of such
> a transition at any time in the future.
>
> And the more time passes, it becomes m
Moin Patrick!
Patrick Ouellette schrieb am Freitag, den 22. April 2005:
> > And the more time passes, it becomes more and more complicated since
> > additional transitions might be interdependent with a transition making
> > the problem even more complicated.
> >
>
> You are very good at repea
On Mon, Apr 18, 2005 at 07:37:40PM -0500, Gunnar Wolf wrote:
> Patrick Ouellette dijo [Sat, Apr 16, 2005 at 01:04:59AM -0400]:
> > (...)
> > Another difference is that testing will get new versions of packages and
> > those versions might (but should not) cause breakage. Testing has had
> > breaka
On Fri, Apr 22, 2005 at 12:21:49PM -0400, Patrick Ouellette wrote:
> On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote:
> > The rules and goals of testing are clear.
> >
> > The more interesting points are the problems of testing that several
> > years of using it have shown.
> >
> > >
On 4/20/05, Jeff Carr <[EMAIL PROTECTED]> wrote:
> Adam M wrote:
>
> >>? I guess I don't understand enough about how the build process works
> >>for the packages in debian but that sounds funny to me. Or I just don't
> >>understand what you mean.
> >
> >
> > To build security patches, you need the
On Wed, Apr 20, 2005 at 04:23:02PM -0700, Jeff Carr wrote:
> Adrian Bunk wrote:
>
> >Let me ask some questions:
> >- How many thousand people can't continue working if the server isn't
> > available?
> >- How many million dollar does the customer lose every day the server is
> > not available?
>
Miquel van Smoorenburg wrote:
If almost everyone you know is a desktop user,
Most everyone I know is an engineer :)
then I can see your
point. But no-one sane running production server systems is going
to run sid.
Well, I'd say no-one sane is running an unqualified/untested
distribution. It doesn
Adrian Bunk <[EMAIL PROTECTED]> writes:
> You say you've deployed Debian sarge and sid in server environments
> (even sarge, although months old security fixes might be missing???).
Sure. Frankly, sarge has better security support than we ever got from
Sun for commercial versions of Solaris. D
Adrian Bunk wrote:
Let me ask some questions:
- How many thousand people can't continue working if the server isn't
available?
- How many million dollar does the customer lose every day the server is
not available?
- How many days without this server does it take until the company is
bankrupt
In article <[EMAIL PROTECTED]>,
Jeff Carr <[EMAIL PROTECTED]> wrote:
>Why not let people choose what they want to use "woody" "sarge" or "sid"
>and never change the names again. I think lots of people are happy with
>how things work now. No need to ever do a release again. Just remove the
>old/
Adam M wrote:
? I guess I don't understand enough about how the build process works
for the packages in debian but that sounds funny to me. Or I just don't
understand what you mean.
To build security patches, you need the same libraries, compilers,
etc... for the release so the built package has t
On Wed, Apr 20, 2005 at 03:18:52PM -0700, Jeff Carr wrote:
> Adrian Bunk wrote:
>...
> >Debian stable is comparable to the enterprise products of e.g. RedHat or
> >SuSE.
> >
> >These distributions are usually installed on servers that are installed
> >and intensively tested once. Security fixes a
> Isn't the process:
>
> 1) make a patch
> 2) give it to the apache developers
> 3) new packaged apache versions have the patch
> 4) patch makes it upstream
> 5) patch no longer needed in debian package
You know, there are security updates for stable releases. You have to
patch those. If there ar
Adrian Bunk wrote:
There are at least three different comparisons:
Debian sid is comparable to e.g. RedHat Fedora or Gentoo (which of these
three is best is a different discussion).
Debian sid is for experienced computer users who always want the latest
software and who can live with a bug here
On Wed, Apr 20, 2005 at 02:06:12PM -0700, Jeff Carr wrote:
> Adam M wrote:
>
> >Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01,
> >2005-01-02, etc..?
>
> Because redhat makes money selling releases.
>
> > The releases are there to provide interface stability. Everyone does
> th
Adam M wrote:
Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01,
2005-01-02, etc..?
Because redhat makes money selling releases.
> The releases are there to provide interface stability. Everyone does
this.
Everyone being other distributions? I disagree. How many Fortune 500
custome
On Fri, Apr 15, 2005 at 04:45:17PM -0400, Patrick Ouellette wrote:
> On Thu, Apr 14, 2005 at 11:59:52PM +0200, Adrian Bunk wrote:
> >
> > On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote:
> > >...
> > > The progression I see is:
> > >
> > > unstable -> testing -> candidate ->
On Mon 04/18/05 16:24, Adam M wrote:
> Also, try providing an efficient stable security build daemons! The
> chroots would have to be rebuilt for each package.
Just a thought, wouldn't this be done quit efficiently with unionfs?
Just install a minimalist root on one partition (or loopback). Then
t
Patrick Ouellette dijo [Sat, Apr 16, 2005 at 01:04:59AM -0400]:
> (...)
> Another difference is that testing will get new versions of packages and
> those versions might (but should not) cause breakage. Testing has had
> breakage issues in the past. Ten days is not enough time to catch all
> the
On 4/16/05, Patrick Ouellette <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-15 at 21:48 -0500, Adam M. wrote:
>
> > Unfortunately this totally changes the purpose of "stable". Stable is
>
> Yes and no. It changes the concept of stable in that stable evolves.
> You still have the static release as
On Fri, 2005-04-15 at 21:48 -0500, Adam M. wrote:
> Unfortunately this totally changes the purpose of "stable". Stable is
Yes and no. It changes the concept of stable in that stable evolves.
You still have the static release as long as we decide to keep that
version of all the packages in the pa
Patrick A. Ouellette wrote:
>The progression I see is:
>
>unstable -> testing -> candidate -> stable
>
>
Unfortunately this totally changes the purpose of "stable". Stable is
there not to provide bug free, up-to-date software releases. Stable is
to provide environmental stability. When someone
On Thu, Apr 14, 2005 at 11:59:52PM +0200, Adrian Bunk wrote:
>
> On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote:
> >...
> > The progression I see is:
> >
> > unstable -> testing -> candidate -> stable
> >
> > The existing rules for promotion from unstable to testing continu
On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote:
>...
> The progression I see is:
>
> unstable -> testing -> candidate -> stable
>
> The existing rules for promotion from unstable to testing continue to be
> used.
>
> Promotion from testing to candidate requires meeting the
> "wesley" == Wesley J Landaker <[EMAIL PROTECTED]> writes:
wesley> On Wednesday 13 April 2005 08:12, Patrick A. Ouellette
wesley> wrote:
>> PROPOSAL FOR DISCUSSION:
>>
>> I suggest we can eliminate the traditional concept of a
>> "release" with the addition of another
On Wednesday 13 April 2005 08:12, Patrick A. Ouellette wrote:
> PROPOSAL FOR DISCUSSION:
>
> I suggest we can eliminate the traditional concept of a "release" with
> the addition of another step in the progression from unstable to
> stable. Additionally, all promotion of packages from one step to
On Wed, Apr 13, 2005 at 11:11:13AM -0500, Gunnar Wolf wrote:
> Date: Wed, 13 Apr 2005 11:11:13 -0500
> From: Gunnar Wolf <[EMAIL PROTECTED]>
> Subject: Re: Temporal Release Strategy
> To: "Patrick A. Ouellette" <[EMAIL PROTECTED]>,
> debian-devel@lists
Patrick A. Ouellette dijo [Wed, Apr 13, 2005 at 10:12:31AM -0400]:
> (...)
> The progression I see is:
>
> unstable -> testing -> candidate -> stable
>
> The existing rules for promotion from unstable to testing continue to be
> used.
>
> Promotion from testing to candidate requires meeting the
34 matches
Mail list logo
