be completed later.
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates
On 25 Oct 2004 13:05:51 -0700, Thomas Bushnell BSG [EMAIL PROTECTED] said:
Anthony Towns aj@azure.humbug.org.au writes:
* One of Testing's goals was to be 95% releasable at all times.
* It hasn't been.
* Why not?
(a) RC bugs
(b) Can't install it
(c) Security vulnerabilities
This is the
The Debian Desktop Distribution will be something like this. I believe
more details will be available soon. Until then,
http://debiandesktop.org/ has a concept paper.
Is this a fork from the main debian distribution?
No. Packages will migrate from `unstable' into the desktop tree by using
On Mon, Oct 25, 2004 at 02:47:49PM +0200, Wouter Verhelst wrote:
I have a simple question for you: have you actually talked to those
currently managing our releases before drafting this GR?
For comparison, when drafting the proposal for package pools and testing,
the folks actually managing the
On Mon, Oct 25, 2004 at 01:05:51PM -0700, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
* One of Testing's goals was to be 95% releasable at all times.
* It hasn't been.
* Why not?
(a) RC bugs
(b) Can't install it
(c) Security
Thomas Bushnell writes:
So the RC bugs should not be blocking release unless they are *new* RC
bugs which don't already exist.
I'd word that a bit differently: the definition of an RC bug should
*never* allow a bug still present in stable now (+ security.stable) to
reach the level of RC.
Jan.
Matthias Urlichs [EMAIL PROTECTED] wrote:
Besides, we'll have a bug database which tracks version numbers. This in
turn means that we have a nice distinction between bugs that are actually
RC in the fix this if we'd want to release Etch tomorrow sense, and bugs
that are RC in the keep this
* Jan Nieuwenhuizen ([EMAIL PROTECTED]) [041028 14:05]:
Thomas Bushnell writes:
So the RC bugs should not be blocking release unless they are *new* RC
bugs which don't already exist.
I'd word that a bit differently: the definition of an RC bug should
*never* allow a bug still present in
* Frank Küster ([EMAIL PROTECTED]) [041028 17:00]:
Matthias Urlichs [EMAIL PROTECTED] wrote:
Besides, we'll have a bug database which tracks version numbers. This in
turn means that we have a nice distinction between bugs that are actually
RC in the fix this if we'd want to release Etch
On Mon, Oct 25, 2004 at 02:03:31AM +1000, Anthony Towns wrote:
Trivial analysis:
()
The release managers have been putting some effort into (a)(1) over the
past year, and there's four of them now instead of just one. How much effort
has the project been putting into the other factors?
I
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [041028 22:00]:
Also note that there are _many_ patches in the BTS for RC (and many other
bugs). But RC bugs do not get fixed in time [0] this also shows that a
number of packages are not being properly maintained and we maybe could
maybe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2004 01:43 AM, Christoffer Sawicki wrote:
The Debian Desktop Distribution will be something like this. I believe more
details will be available soon. Until then, http://debiandesktop.org/ has a
concept paper.
Is this a fork from the
Clemens Schwaighofer [EMAIL PROTECTED]:
On 10/25/2004 12:44 AM, Eduard Bloch wrote:
| - all the packages are out of date? Well, though luck, this is what the
| whole issue is about. We need to release faster. Faster releases are
| only feasible if enough developers are motivated. They
Every half a year you make a snapshot of testing, so you have a kind of
stable release. Perhaps not 100% stable like stable, but at least not so
horrible outdated.
The Debian Desktop Distribution will be something like this. I believe more
details will be available soon. Until then,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2004 12:44 AM, Eduard Bloch wrote:
| Ehm... what is wrong with running stable with backports? Why do you not
| install a such combination for your parents, what is wrong with that?
|
| - Missing few important pieces of software? Backport them
* Marco d'Itri wrote:
My solution? Stop releasing, and leave this to entities which are
motivated enough (or well-financed enough, which is the same thing)
to do it.
You are about seven month too late. Or about five too early.
Norbert
Hi, Eduard Bloch wrote:
Maybe. What is the alternative? Continue with the current method and
release Edge... 2009 or so?
The beast will be called Etch, not 'Edge'. Its timing, for the
most part, depends on a couple of sticklers like multi-arch support,
archive split and resolve the GFDL
On Sat, Oct 23, 2004 at 10:44:58PM +0200, Gergely Nagy wrote:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting
On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
Gergely Nagy [EMAIL PROTECTED] writes:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing
On Sun, Oct 24, 2004 at 05:44:31PM +0200, Eduard Bloch wrote:
Remember, Debian is a volunteer project, you cannot force people to do
something they do not want to.
Motivation is the only factor to make them do things. Having to care
about the release in order to continue the fun work leads
On Sun, Oct 24, 2004 at 05:51:47PM +0200, Eduard Bloch wrote:
#include hallo.h
* Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
not look appear as critical for maintainer, or not important enough to
touch
package in the holy frozzen state). Such bugs are a disaster, they make
our
On Sun, Oct 24, 2004 at 05:57:05PM +0200, Eduard Bloch wrote:
#include hallo.h
* Marco d'Itri [Sat, Oct 23 2004, 10:06:24PM]:
On Oct 23, Eduard Bloch [EMAIL PROTECTED] wrote:
ABSTRACT
You are trying to force developers to work on item x, which they dislike,
by forcing them to not
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:00]:
#include hallo.h
* Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
not look appear as critical for maintainer, or not important enough to
touch
package in the holy frozzen state). Such bugs are a disaster, they make
our definition of a
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:10]:
At least they won't poison Sid with fresh things that may others life
more difficult. Eg. new library versions.
And why should that work better than now? The developers _are_ asked to
not poison sid. The advantage of testing is however that we
On Sun, Oct 24, 2004 at 06:02:38PM +0200, Eduard Bloch wrote:
#include hallo.h
* Wouter Verhelst [Sun, Oct 24 2004, 11:41:33AM]:
Very few bug reports from testing users are of any value at all.
I respectfully disagree here.
With most of my packages, bugs get filed only when the
#include hallo.h
* Nikita V. Youshchenko [Mon, Oct 25 2004, 12:17:15AM]:
In fact, existance of testing allows me to be a user and a developer at the
same time.
You may state that such reason has nothing to do with release process, for
which testing was originally proposed. Yes, I agree.
On Oct 24, Eduard Bloch [EMAIL PROTECTED] wrote:
whole issue is about. We need to release faster. Faster releases are
only feasible if enough developers are motivated. They are motivated
if Unstable is blocked and they must care about the release instead
of working on stuff that
On Sun, Oct 24, 2004 at 05:35:57PM +0200, Eduard Bloch wrote:
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
Probably there are non-technical problems with the uncoming release. But
There are, as described before. For example, I cannot see any life sign
of our FTP masters. How
Anthony Towns aj@azure.humbug.org.au writes:
* One of Testing's goals was to be 95% releasable at all times.
* It hasn't been.
* Why not?
(a) RC bugs
(b) Can't install it
(c) Security vulnerabilities
This is the crux of the problem, I think, but
Steinar H. Gunderson wrote:
On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate
On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
Gergely Nagy [EMAIL PROTECTED] writes:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing
#include hallo.h
IMHO it's somewhat silly to stop the experiment now and drop testing.
Although there are problems with testing, there *are* well-known positives
of having it.
Yes, there are problems with current scheme. So one should write down the
facts and do a careful, in-detail, emotion
#include hallo.h
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
#include hallo.h
IMHO it's somewhat silly to stop the experiment now and drop testing.
Although there are problems with testing, there *are* well-known positives
of having it.
All the known positives are outweighted
#include hallo.h
* Gergely Nagy [Sat, Oct 23 2004, 10:44:58PM]:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details.
Doing
#include hallo.h
* Steinar H. Gunderson [Sat, Oct 23 2004, 10:36:16PM]:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details
#include hallo.h
* Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
not look appear as critical for maintainer, or not important enough to touch
package in the holy frozzen state). Such bugs are a disaster, they make
our definition of a Stable release absurd. Yes, Debian Stable has become a
#include hallo.h
* Marco d'Itri [Sat, Oct 23 2004, 10:06:24PM]:
On Oct 23, Eduard Bloch [EMAIL PROTECTED] wrote:
ABSTRACT
You are trying to force developers to work on item x, which they dislike,
by forcing them to not work on item y, which they like more. You are
apparently oblivious to
#include hallo.h
* Wouter Verhelst [Sun, Oct 24 2004, 11:41:33AM]:
Very few bug reports from testing users are of any value at all.
I respectfully disagree here.
With most of my packages, bugs get filed only when the transition to
testing has been complete for quite a while already,
On Sun, Oct 24, 2004 at 03:53:23PM +0400, Nikita V. Youshchenko wrote:
#include hallo.h
Yes, there are problems with current scheme. So one should write down the
facts and do a careful, in-detail, emotion-less analysis of each problem
and it's reasons.
Trivial analysis:
* One of
On Sun, Oct 24, 2004 at 07:32:18AM +0200, Martin Schulze wrote:
You _are_ aware that this is approximately how it was done before woody, no?
With three 1-month test cycles to get frozen into a reasonable and releaseable
state?
Eh? potato was frozen on the 16th January, 2000; it was released
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details.
Doing this would result in many users who currently run testing
Eduard Bloch wrote:
#include hallo.h
* Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
not look appear as critical for maintainer, or not important enough to
touch
package in the holy frozzen state). Such bugs are a disaster, they make
our definition of a Stable release absurd. Yes,
On Sun, Oct 24, 2004 at 08:44:47PM +0200, Gergely Nagy wrote:
very big snip
Getting people motivated should not be done in a way that makes - I hope
- many of them unhappy. To get back to your point - blocking uploads to
unstable will not make more people concentrate on the release. They'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
#include hallo.h
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
#include hallo.h
IMHO it's somewhat silly to stop the experiment now and drop
testing. Although there are problems with testing, there *are*
well-known positives
On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
One of the first and most known things: it puts a lot of outdated packages on
the head of our users! Yes, testing sounds like a good compromise for people
that want to have bleeding edge software without taking the risk, but we saw
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
IMHO it's somewhat silly to stop the experiment now and drop
testing. Although there are problems with testing, there *are*
well-known positives of having it.
All the known positives are outweighted by the negative issues as
described before
and in agreement of the
release manager(s), this is the way to go. Otherwise, take it as a real
GR draft which should be completed later.
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop
On Oct 23, Eduard Bloch [EMAIL PROTECTED] wrote:
ABSTRACT
You are trying to force developers to work on item x, which they dislike,
by forcing them to not work on item y, which they like more. You are
apparently oblivious to the fact that most developers will probably
spend their time on item w
On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing
El sb, 23-10-2004 a las 12:56 +0200, Eduard Bloch escribi:
[...]
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details.
- about
Gergely Nagy [EMAIL PROTECTED] writes:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff
Hi, Brian Nelson wrote:
Very few bug reports from testing users are of any value at all. They
usually either report some transient dependency problem that the
maintainer can't fix anyway, or report something that has already been
fixed in the unstable package.
You can't fix *this*
On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
Gergely Nagy [EMAIL PROTECTED] writes:
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing
radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details.
Doing this would result in many users who currently run
Eduard Bloch wrote:
Debian Testing is not stable and is not mature. It is full of shitty bugs
(let me define this term as name for ugly bugs that bother the users but do
not look appear as critical for maintainer, or not important enough to touch
package in the holy frozzen state). Such bugs
56 matches
Mail list logo
