Re: Drop testing

[Ola Lundqvist]

Hello

I may write exactly the same thing as Steve Langasek but I just have
to tell why I would like to keep testing.

On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
> #include 
> 
> > > Some improvements have already been proposed by Eduard Bloch and
> > > Adrian Bunk: freezing unstable while keeping testing.
> > 
> > Jerome, please, you could have asked me. I prepare an internal GR draft
> > for exactly this issue, but it is to be made public on the day of the
> > release, and better not before. We should concentrate on making the
> > Sarge release ready, NOW. Do not start another flamewar.
> 
> To hell with it, the avalanche has already started.
> 
> The attached paper was written down as a GR draft, but if the problem
> can be solved peacefully by a consens on d-d 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 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.

The sync problems will not exist if we drop testing?

>  - about the "filtering updates for frozen" - yes, some additional
>manpower is required but that work must be done. The problems with
>Testing synchronisation are not of pure technical nature, they are
>social problem, and so they should be solved by people and not
>scripts.

So this means that we need more FTP-maintainers, or more effort spent
by them.

> Regards,
> Eduard.
> -- 
> Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei
> Katzen.
>   -- Sprichwort

> ABSTRACT
> 
> 
> I propose that the Debian project resolve these questions:
> 
>  - should we continue using Testing and the gradual freeze model?
>  - should we change the freeze model to the tristate model (similar to the one
>from the old days)
> 
> Possible choices:
> 
>  - stop using Testing distribution and change to the Tristate freeze model
>  - stop using Testing, the release manager should develop the freeze model
>  - continue using the current release model
> 
> RATIONALE
> -
> 
> Why is testing bad?
> ==
> 
> 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 
> in
> the past years that testing created more problems that it was really worth.

Well testing is not a perfect solution for people to use as it do not contain
security updates and lack updated packages. Yes, and I do not think that
is a bad thing. I actually think that is what you can expect. If people
want to have a secure system they should use stable and if they want
bleeding edge they should use unstable. That is their decision and not
ours. Testing is a good thing to use for development and not something
you sould see as a form of stable. If that were the case it should be named
prerelease or something.

As a testbed testing is something good. You will not have the most critical
known bugs in the system so you can keep on testing things. We also have
a good mixture of people using unstable and testing (I know many people that
use unstable and also many people that use testing), so that is not a problem.

> The only advantages guaranteed by its structure was a promise to keep an
> installable set of packages. Which does not promise a useful/bugfree piece

Yes and this is a very good thing as we did have problems with this before
testing was created.

> of software. I think we should be fair to our users when we tell them to
> report bugs - we should tell all of them that reporting bugs in Sarge is
> often duplicated work because the problem has been fixed in Unstable.  I

I do not know if you have noticed that people tend to report bugs at
whatever they are using. I get a lot of bugs on packages in stable, testing
and unstable. Sometimes even exprimental. If we drop testing we will still
keep getting bugs from people that use unstable (and not a fully updated one).
I do not see the big problem with this. Replying to the mail and closing the
bug is very easy and do not take much time. I maintain about 60 packages
(at my spared time) and I do not see this as a big problem.

> think we should be fair to our users - we should not put a lot of buggy
> software onto their heads (promising some bogus stability at the same time),
> without having

Re: Drop testing

[Christoffer Sawicki]

> > 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 a 
script similar to the one used for `testing'. The main difference is the 
conditions thas has to be fulfilled for a package to migrate.

*/ Christoffer Sawicki <[EMAIL PROTECTED]>

Re: Drop testing

[Manoj Srivastava]

On 25 Oct 2004 13:05:51 -0700, Thomas Bushnell BSG <[EMAIL PROTECTED]> said: 

> Anthony Towns  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 I'm a little confused.

> How does (a) contribute to this?  The assumption behind an RC bug is
> "we can't release with this bug unfixed".  But the problem is that,
> of course, we *do*, and we *have*, because many RC bugs are in
> things we have already released.  In other words, woody has RC bugs
> in it Right Now.  But that doesn't stop us from continuing to call
> it stable.

Did we know it was a RC bug when we released it? I think
 not. We do not live in a environment where we have perfect
 information,  so we do the best we can. However, if we let known RC
 bugs slide, the resulting release would be far worse -- since now ew
 have bugs we do not know about at the point of release, and bugs that
 we did, and let slide.

> So the RC bugs should not be blocking release unless they are *new*

No. If they are release critical, they are critical -- and
 they block the release. Anything else impacts the quality of
 distribution and starts a slippery slope towards mediocrity.

We have already blown it as a distribution with cutting edge
 releases -- our reputation rests on quality, and r0ock solid
 stability.

> RC bugs which don't already exist.  In other words, a new stable
> release shouldn't be worse, but it doesn't have to be maximally
> better.  It shouldn't have new RC bugs, but it's tolerable if it
> continues to have the same old ones.

I vehemently disagree. We are not people who have found common
 cause to only slowly deteriorate towards mediocrity; we are folks who
 are trying to put together the best possible distribution of Linux.

If people want a good enough distribution, they can try
 mandrake or red hat.

manoj
-- 
Mount St. Helens should have used earth control.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Drop testing

[Clemens Schwaighofer]

-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 main debian distribution?

lg, clemens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgXGzjBz/yQjBxz8RAmYoAKDhEcoRBhsv4lil50ARdAQjlSsE9gCgyHxN
goA9JmMB0E0T01W1ubktOWI=
=ZLA7
-END PGP SIGNATURE-

Re: Drop testing

[Andreas Barth]

* 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 think a way to force the maintainer to give over maintainership if he
> is overloaded with other work and he cannot fix the package in time.

I plan to go through the packages that are not released with sarge, and
propose to orphan / delete some / most of them.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Javier Fernández-Sanguino Peña]

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 think there has been a lot of effort put in (a)(2), and (b)(1),
throughout the year, it's just that we have more software (and bugs) than
people willing (or with sufficient time or capabilities) to fix them.  We
should either have more people or less software. I think there's only one
reasonable answer to that dilemma. 

The fact that a lof of effort goes into (a)(2) but does not result into a
release in the time-frame we planned also makes people abandon their effort
due to desesperation. No matter how many RC bugs we fix in the distribution
there are always new ones on the road ahead.

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 think a way to force the maintainer to give over maintainership if he
is overloaded with other work and he cannot fix the package in time.

> > Probably there are non-technical problems with the uncoming release. But
> > there are technical problems also, yes? Why not eliminate those? If instead
> > of each mail in this thread a single RC bug that affects sarge was fixed,
> > probably there could be *zero* such bugs now.
> 
> Why not do both? Every time you post a mail to a thread like this, fix an
> RC bug. This is the "ObBug:" rule.
> 

ObBug: 277099

Regards

Javier

[0] For obvious reasons this usually happens with popular software or
important parts of the system. Take a look at the (non-RC bugs) open
against sysklogd, just to pick one which I've been looking today (not
necessarily the worst one).


signature.asc
Description: Digital signature

Re: Versioned bugs in the BTS (was: Drop testing)

[Andreas Barth]

* 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 tomorrow" sense, and bugs
> > that are RC in the "keep this out of testing" sense.
 
> This sounds great, and I heard that it has been promised for after the
> sarge release, sounding as if it was implemented yet. Is the counterpart
> also implemented, namely testing scripts that take this information into
> account? 

The implementation of version in the BTS is done so that the second is
not _so_ hard to implement (speaking as someone who has seen lots of
parts of britney).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Andreas Barth]

* 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 stable now (+ security.stable) to
> reach the level of RC.

We _have_ RC-bugs in woody - even RC-bugs we won't fix.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Versioned bugs in the BTS (was: Drop testing)

[Frank Küster]

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 out of testing" sense.

This sounds great, and I heard that it has been promised for after the
sarge release, sounding as if it was implemented yet. Is the counterpart
also implemented, namely testing scripts that take this information into
account? 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Drop testing

[Jan Nieuwenhuizen]

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.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

Re: Drop testing

[Anthony Towns]

On Mon, Oct 25, 2004 at 01:05:51PM -0700, Thomas Bushnell BSG wrote:
> Anthony Towns  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 I'm a little confused.
> How does (a) contribute to this?  The assumption behind an RC bug is
> "we can't release with this bug unfixed".  But the problem is that, of
> course, we *do*, and we *have*, because many RC bugs are in things we
> have already released. 

To paraphrase: "The problem is that, of course, this is not a problem."

Releasing with a hundred known security problems in the kernel is
worse than releasing with a dozen unknown security problems in Priority:
extra packages. We can, and indeed have to, accept the possibility of the
latter; we shouldn't accept the former. The existance of various RC bugs
in woody, now or when it was released, and the number of RC bugs still
present in testing sit somewhere on that scale between those two extremes.
Where we chose to make a cut off point and release is likewise somewhere
between those two points.

(a) is about failing to make sure we're on the correct side of that cut
off point.

> So the RC bugs should not be blocking release unless they are *new* RC
> bugs which don't already exist.  

That's not really the case. Though, even if it were, sarge would still
fail to be releasable.

> As for (b), the solution, if there is one, is to have the installer
> folks spend time targeting testing all the time.  

In my experience, claims of the form "The only possible solution to this
problem is " are almost invariably wrong, or at least need to be
heavily qualified.

The drawback is that "targeting testing" for development work is usually
a losing proposition -- there's a deliberate delay in putting stuff
into testing, and any delay is a nuisance when you're waiting on a fix
before you can do more development. Even targeting unstable has proven
cumbersome for the d-i folks.

> As for (c), the solution in my opinion is to allow security fixes to
> migrate into testing without having to wait for the normal delay.

That already happens, just set urgency=critical in the changelog. If
you forget, reupload, or contact a release manager.

It's not enough, because security bugs aren't always fixed in a timely
manner in unstable; see [0] eg. It's also not enough, because uploads
to unstable can easily be unsuitable for testing, even through no fault
of the package's maintainer.

Is it coincidence that all your proposed resolutions involve
situations where you couldn't be expected to contribute? (RC bugs don't
matter! Installer team needs to refocus! Security stuff is already
handled, just needs code changes!)

Cheers,
aj

[0] http://lists.debian.org/debian-release/2004/08/msg00174.html

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Anthony Towns]

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 release and the archive didn't really
get involved or contribute 'til after a proposal was drawn up, to the
best of my recollection. OTOH, they did get cc'ed on the discussion,
and their advice was actively sought out.

The benefit of conducting Debian as openly as possible is that you don't
have to get particular people's advice to come up with good solutions --
you can just troll through the archives for all the data you need.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Christoffer Sawicki]

> 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, http://debiandesktop.org/ has a 
concept paper.

*/ Christoffer Sawicki <[EMAIL PROTECTED]>

Some more pressure on maintainers (was: Drop testing)

[Erik Schanze]

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 are motivated
> |    if Unstable is blocked and they must care about the release instead
> |    of working on stuff that makes "more fun".
> 
> fast releases with removing testing? I think you go the wrong way.
> 
> Faster release with having something between stable and testing.
> 
> Snapshot!
> 
> 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.
> 
In addition, every package that have RC bugs should be excluded from this
snapshot. IMO this would encourage maintainers to fix RC bugs asap,
especially if other packages depend on theirs. ;-)

Another point is the short delay of 10 days.
In the last "build panic" end of august many packages wait over 10 days
in build queue and enter immediatelly testing after they were build without
some test period in unstable.

IMO it would be better to start a wait of 20 days in unstable, if the
package _reaches_ unstable. A longer delay can result in a cleaner testing.

More radical is to prevent new uploads or transition of the new version into 
testing, if there are RC bugs open and new upload doesn't solve at least one. 
(to detect this, "Closes: #" must in changelog)
It would encourage maintainers to fix at least one RC bug, if they would have 
new verion uploaded. 

> Seriously, most people I know run testing on their boxes. Why? It is
> quite stable (Actually extremly stable compared to other "final release
> distros") and very up to date.
> 
ACK.
In my understanding, testing should be everytime in shape to release a snapshot
at any time. For development and broken packages we have experimental and 
unstable.


Regards,

Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 30. Oktober 2004  *
 Info: http://www.linux-info-tag.de *




pgpfCedTpwRiJ.pgp
Description: signature

Re: Drop testing

[Matthias Urlichs]

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 problem", all of which have nothing
at all to do with testing.

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 out of testing" sense.

In other words, testing will help (even more, as IMHO it already does
this) to reduce the number of bugs we actually need to care about if we
want to release, which is a Good Thing.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Drop stable (was: Re: Drop testing)

[Norbert Tretkowski]

* 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

Re: Drop testing

[Clemens Schwaighofer]

-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
so everybody should create their own backports, break things, etc. Not
good in my opinion
|  - 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 are motivated
|if Unstable is blocked and they must care about the release instead
|of working on stuff that makes "more fun".
fast releases with removing testing? I think you go the wrong way.
Faster release with having something between stable and testing.
Snapshot!
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.
Seriously, most people I know run testing on their boxes. Why? It is
quite stable (Actually extremly stable compared to other "final release
distros") and very up to date.
What should those people use? Stable? No way, too old. Unstable? Breaks
often. No way. So what will they do, go away and search another distro.
And I am sure there will be a lot who reported bugs.
Less bug reports means less feedback, less bug fixing. And this doesn't
help to make a faster release cycle.
|>Freezing unstable will get you nothing compared to what we have now.
|
| What do we have? Release times reaching eternity? Testing, full of
| hidden / obscure bugs that have not been visible in Sid, or that are
| fixed in Sid but the update got stuck somewhere?
Thats why it would be better to do snapshot releses. Nowadays with
thousands of packages and thousands of dependencies, it is completly
impossible to make 100% stable release. Just look at Gnome in Debian. It
takes ages to come into unstable. There are so many problems, all the time.
- --
[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBfgJJjBz/yQjBxz8RAvaDAKCyyi9ecNnREfcHUWSUjEsgHq/fAgCfd5S7
k99uWI0hwiA0d0wn9fv9d8g=
=BBg7
-END PGP SIGNATURE-

Re: Drop testing

[Thomas Bushnell BSG]

Anthony Towns  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 I'm a little confused.

How does (a) contribute to this?  The assumption behind an RC bug is
"we can't release with this bug unfixed".  But the problem is that, of
course, we *do*, and we *have*, because many RC bugs are in things we
have already released.  In other words, woody has RC bugs in it Right
Now.  But that doesn't stop us from continuing to call it stable.

So the RC bugs should not be blocking release unless they are *new* RC
bugs which don't already exist.  In other words, a new stable release
shouldn't be worse, but it doesn't have to be maximally better.  It
shouldn't have new RC bugs, but it's tolerable if it continues to have
the same old ones.

As for (b), the solution, if there is one, is to have the installer
folks spend time targeting testing all the time.  I don't know if this
is actually worth the effort or not.

As for (c), the solution in my opinion is to allow security fixes to
migrate into testing without having to wait for the normal delay.

Thomas

Re: Drop testing

[Graham Wilson]

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 comes?

I just had two packages I work on accepted into the archive. That means
the FTP masters are alive and active, right?

-- 
gram

Drop stable (was: Re: Drop testing)

[Marco d'Itri]

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 makes "more fun".
I wonder how you did end up thinking this may be true.
If I don't feel like fixing bugs in one of my packages (think mutt) then
I'm going to do something else. But I have a long list of tasks between
"work on new packages in unstable" and "fix bugs in mutt".

> Motivation is the only factor to make them do things. Having to care
> about the release in order to continue the "fun work" leads to
> motivation.
I don't feel motivated to work on releases which are not deployable
because when they get old they need tens of backports to be useful and a
knoppix CD to be installed.
Anyway unstable is good enough for my needs, and testing with a few
minor changes could be even better.
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.

-- 
ciao, |
Marco | [8730 doXLPaWz36Tmo]


signature.asc
Description: Digital signature

Re: Drop testing

[Eduard Bloch]

#include 
* 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. However, the above 
> argument shows why testing *is useful for real life* even in it's current 
> state.

Let's assume that I agree with you, for a moment.

> As for role of testing in the release process, I believe there is plenty of 
> room to improve.

Yes, a lot.

> You write, biggest problem with testing is outdated packages. Yes, probably 
> you are right. So, some action should be taken to overcome that. I can't 
> immidiatly answer what exact actions will help, but it's a good direction 
> to think on. Let's try.
> So what makes package's path to testing long?
> - - RC bugs. Here nothing else could be done other than fixing the bugs. 
> Personally I thing that some infrastructure change could be useful here to 
> force maintainers fix RC bugs. Probably any RC bug without activity for 

I already collect some ideas about creating an anti-karma list. Listing
maintainers that keep real bugs open for a while (based on the impact;
Severity: normal and above for all packages, minor for Section:
standard++ packages), multiplied with the time they have existed and
summ'ed over all packages. The results would be quite interesting, I
expect even some "core" developers among the crap-producing part.

> several (say, 5) days should "become more public", some mechanism should 
> be used to encourage non-maintainers to work on the issue.

Okay. This could be done with the wnpp listings on d-d-a sorted by the
impact of the bugs.

> - - Complex dependency chains. Probably some scheme could be used to decrease 
> the effect of those. E.g. build mostly against testing, not against sid, 
> and use build-deps from sid only if relly required (what exactly "really 
> required" means here, should be defined separately).

This is another thing I have proposed a solution, a while ago. Many
maintainers use Build-Depends to control transitions in Sid, while this
implicitely breaks Testing transtion. There should be a
Build-Depends-Min: field where the oldest required version of libFoo is
listed. So t-p-u autobuilders could pick this minimal set of
Build-Dependencies which is sufficient and would make Testing transition
possible without having the binary transition.

Yes, there are problems based on ABI incompatibilities that could be
hidden with this method, but that is the price for having working
build-debs and sane transtition times (in average). IIRC a quarter of
Testing cannot even be built based on Testing Build-Deps.

And the last part is not hidding open bug reports as we currently do
(Sid packages close bug reports that still exist in Testing/Stable for
months/years, months after that). I was told that the needed code for
the BTS is almost ready and they just wait for the release to activate
it.

> > But many maintainers simply do not care much
> > about testing, Unstable runs fine for them.
> 
> Do you really think that this is the point? Do you have statistics?

No, but some web survey can surely be done. There is something on
http://www.debian-administration.org/?poll=3 but there are not enough
votes (IMHO) base any statement on it.

Regards,
Eduard.
-- 
Jede einem Menschen zugefügte Beleidigung, geleichgültig, welcher
Rasse er angehört, ist eine Herabwürdigung der ganzen Menschheit.
-- Albert Camus

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 06:02:38PM +0200, Eduard Bloch wrote:
> #include 
> * 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, except when the bug
> > is a /really/ severe one (severity grave or critical).
> 
> Counter example: you fix a bug in Sid but insufficiently (and you do not
> know for sure). Few users continue reporting bugs in the Testing
> version. You ask them to test the Sid version. But Sid scares them

In that case, you build a package against the testing libraries, upload
that to your people.d.o webspace, and ask them to test that.

If they are not willing to test that either, then they are not helpful
and you cannot fix the bugs that bother them. This will stay the same
regardless of whether or not there is a testing.

> and they promise to wait for the update to be in Sid. Then, you will
> wait weeks for the acknoledgement and the bug may still be in Testing
> in this time. And it will take another two weeks for a real fix to
> slip into Testing.
> 
> That is not fun. That is overhead which creates confusion.

Because you're doing it wrong.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Andreas Barth]

* 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 have some
chance to un-do broken actions.

> > they like less than x but still more than y. So this will at least fail,
> > and probably hurt debian too.

> Maybe. What is the alternative? Continue with the current method and
> release Edge... 2009 or so?

If we could get back to facts, our main problem is _not_ that sarge is
not in release-quality. Sarge is (mostly) in very good shape, and the
remaining problems would be there also with your proposal.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Andreas Barth]

* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:00]:
> #include 
> * 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
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's

> a) The release time would be shorter

I would like to see a prove of this.

> b) It would be up to humans (and not some obscure scripts) to decide whether 
> the bugs deseves a fix or not

This is already the case. If the humans decide that a bug should be
fixed, they can either just do it, or at least upgrade the bug to
RC-grade. If they decide that it is actually not so bad that it requires
a fix for the release, they could downgrade it.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:57:05PM +0200, Eduard Bloch wrote:
> #include 
> * 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 the fact that most developers will probably
> > spend their time on item w (which is probably not a Debian task), which
> 
> At least they won't poison Sid with fresh things that may others life
> more difficult. Eg. new library versions.
> 
> > they like less than x but still more than y. So this will at least fail,
> > and probably hurt debian too.
> 
> Maybe. What is the alternative? Continue with the current method and
> release Edge... 2009 or so?

Improve the way testing works. There are flaws, nobody is contesting
that; but just dropping the whole idea because of them flaws is akin to
throwing away the child with the bath water.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:51:47PM +0200, Eduard Bloch wrote:
> #include 
> * 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
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's
> 
> a) The release time would be shorter

That remains to be seen.

> b) It would be up to humans (and not some obscure scripts) to decide
> whether the bugs deseves a fix or not

That is the case now, too. If the release managers deem it appropriate,
they can always override the testing scripts. However, the scripts
(which are far from obscure -- perhaps they are from your POV, but that
is not the same thing) generally do 'the right thing' by themselves,
which results in a massive reduction of manual work. That is a good
thing.

> Yes, some manpower would be required for this process.

Uh, I think that is a grave understatement.

> But fellow maintainers could be involved into process of evulation of
> the quality of a proposed upgrade.

That is the case now, too. You should try and have a look at
debian-release@lists.debian.org once.

> > currently frozen in testing, the situation is exactly what it is now;
> > the maintainer and RM have to decide whether putting this fix into
> > testing (or frozen) and possibly introducing new, more important bugs is
> > warrented by the ugliness of the bug. If the package is one of the large
> > majority of packages that are _not_ currently frozen in testing, then it
> 
> "not currently"? In my solution, the whole Sid archive would be frozen.

s/solution/proposal/

Even if dropping testing would be a good thing, then I still don't
believe it's a good idea to freeze the whole distribution in one go.
Freeze the base system first, freeze the rest when the base system is
good to go.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

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 to
> motivation.

Indeed.

Having the idea that the release takes ages, and that the "fun work"
will not come back in the near future, does not.

> > >Testing synchronisation are not of pure technical nature, they are
> > >social problem, and so they should be solved by people and not
> > >scripts.
> > 
> > Yes, testing synchronisation is not a purely technical matter. Nor is it
> > purely social, so the testing scripts, which automatically keep stuff in
> > sync, are a real help. On top of that, package maintainers coordinating
> 
> They are overhead.

They most certainly are not. It certainly is a help to be able to see
what packages are in a mostly-releasable state just by looking at those
that are in testing, and those that are not.

I have a simple question for you: have you actually talked to those
currently managing our releases before drafting this GR?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Francesco Paolo Lovergine]

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 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 fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.
> 
> 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.

The true solution is a multi-release BTS, not dropping testing. And
being maintainer/uploader of quite a good number of packages, I can say
those cases of testing-only problems is a minority. We have also
reports which are (yet now) stable-only, for what I can see. A proper
BTS implementation for that could help in tracking things appropriately. 

-- 
Francesco P. Lovergine

Re: Drop testing

[Francesco Paolo Lovergine]

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 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 fall
> back to stable + backports or switch to another distro (ubuntu being a
> likely candidate), which in turn, would result in less bugreports and a
> less stable distribution. I, for one, wouldn't run unstable on my
> parents' box, whereas testing proved to be quite reliable there.
> 

Absolutely agree. DON'T drop testig. I'm using testing since ages here
on a good deal of boxes with different configurations and used by 
naive users without big gotchas. It helps me to check problems
in -sarge- without using sid on any computers, but for my personal ones.
It helps a lot in debugging and testing upgrades from woody.
It helps in creating custom distros starting from an archive in 
a reasonable state.

And, about the general 'shape' of testing: are you conscious that
testing is _now_ in very better general shape than other 'released'
distros? Are you consciuous that _our_ requirements about 
level of quality is higher than that of many blasonated 
(also $$$) distros?

> Freezing unstable will get you nothing compared to what we have now.
> Those who don't care about a release, will not care that way either,
> just their complaints will get louder and more frequent. Those who are
> willing to do the work neccessary for the release are already trying to.
> 

I agree too. I add also that dropping testing would not help in having
up-to-date versions in stable. Simply, we would have a lng freeze
in sid, due to the current size of archive (i.e. package per developer)
and number of RCs. Versions would be obsolete in any way.

> Remember, Debian is a volunteer project, you cannot force people to do
> something they do not want to.
> 
> >  - about the "filtering updates for frozen" - yes, some additional
> >manpower is required but that work must be done. The problems with
> >Testing synchronisation are not of pure technical nature, they are
> >social problem, and so they should be solved by people and not
> >scripts.
> 
> Yes, testing synchronisation is not a purely technical matter. Nor is it
> purely social, so the testing scripts, which automatically keep stuff in
> sync, are a real help. On top of that, package maintainers coordinating
> with each other (the social part) is welcomed too, and should be
> encouraged. (And those who break a transition should be kicked in the
> ass, so they won't try it again :P)
> 
> I firmly believe that fixing the problems with testing (mainly
> testing-security at this point in time) would be MUCH better than
> dropping testing and freezing unstable before the next release.
> 

You are my hero :-P

-- 
Francesco P. Lovergine

Re: Drop testing

[Miles Bader]

"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.
>
> I don't think so.
>
> For me, existance of testing allows running more-or-less up-to-date systems 
> without facing current development problems with packages/subsystems that 
> I'm not involved in.

Yeah, me too.  I run unstable at work (where I have a fast/reliable net
connection), and testing at home (where I don't).  Testing seem to hit a
sweet spot in the reliability/update-frequency continuum for me.

Now, whether testing does or does not help the "make a new stable release"
problem, I don't know -- but it most certainly _is_ useful for normal
users, and er, aren't they the whole (or at least most of the) point?

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Drop testing

[Steve Langasek]

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 
> in
> the past years that testing created more problems that it was really worth.

Excluding RC bugs and complications, the wait time for a package to reach
testing from unstable is 10 days.  The lifetime of a stable release is much
longer than 10 days, during which time all of those packages are "outdated".
Why is this a criticism of testing, but not of stable?

> 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 are a disaster, they make
> our definition of a Stable release absurd. Yes, Debian Stable has become a
> buggy stable release. Just face it.

This is both an unhelpful, subjective assessment of testing, and not
something that would be fixed by dropping testing.  If there are
undocumented bugs in testing that you consider release-critical, the answer
is for you to file the reports to document them.  If the maintainer
disagrees with you about whether it's release-critical, you can appeal the
question to the release team -- or, better yet, prepare a patch on your own
that's good enough that the maintainer will apply it without any further
need for arguing over severities.

If you're not willing to do the above, or if for whatever reason this
doesn't work, eliminating testing isn't going to help you either.  The bugs
would still be there, whether "there" is named "testing" or "unstable".

So no, I won't "just face it".  If you're not happy with the quality of the
software going into sarge, there is a public BTS available for you to use in
addressing these problems.  Given the declining number of RC bugs open
against sarge, however, I would offer that this is something of a minority
view.

> The major goal (making Freeze periods shorter) was not reached. The second
> goal (faster releases) was not reached. 

There's a lack of useful evidence on this question.  Among the other factors
involved which make it difficult to determine what the effect of testing has
been on release cycles, we have:

  - the number of released architectures
  - the number of packages targetted for the release
  - the number of developers involved who must coordinate among themselves
to bring about a release
  - individual developers' life circumstances and resource committment to
Debian
  - individual RC issues that introduce release delays
  - a very small sample size

The last point is particularly relevant, given that most of sarge has not
frozen yet at all.  While the freeze for base has been much longer than we
might have hoped, for most packages it has had zero impact so far; and we
have every reason to believe that a quick freeze of the rest of the system
will be possible once the current blocking issues are sorted out.

> The third goal (better software quality in the development branch) was not
> reached, at most partially (the users did not have to deal with PAM bugs
> this time, hahaha).

Subjective, not to mention insulting to the efforts of all the developers
who have been doing their part to make sarge a top-quality OS.  Or did you
have statistics on the frequency & fix rate of RC bugs in pre-sarge testing
vs. unstable prior to the introduction of testing?

> So how would the removal of Testing help?
> =

>  - frozen would have better software - more up-to-date upstream versions with
>less ugly upstream/packaging bugs

Unsubstantiated assertion.  The software would be more up-to-date at the
beginning of the freeze, but the freeze would almost certainly last longer
since there would be no way to deal with RC-buggy package versions except
for fixing them or dropping them after the freeze has started; so by the end
of the freeze, the software is likely to be *less* up-to-date.

>  - maintainers would actually be forced to fix 

Er, as opposed to what?

> A possible future model for the release cycle and freze method will be so
> called Tristate freeze model. It consists of three states:

>  - PRE-FREEZE, 2-3 Weeks before the freeze day. A frozen directory is created
>on a dedicated machine and release managers can start testing the freeze
>management scripts. Release team and few selected users should have access
>to this resource. This testing environment is not stable and may (or not) 
> be
>purged before the main freeze begins
>  - MAIN FREEZE: takes three weeks, beginning from the freeze day. Unstable
>branch will be moved to "frozen".  Packages uploaded to "frozen" or
>"unstable" are mapped to "frozen-candidates

Re: Drop testing

[Nikita V. Youshchenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> #include 
>
> * Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > > #include 
> >
> > 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.

I don't think so.

For me, existance of testing allows running more-or-less up-to-date systems 
without facing current development problems with packages/subsystems that 
I'm not involved in.

For a long time, I use mixed (stable/)tesing/sid systems. Most of packages 
are from testing, sid version is used for a package if testing version 
doesn't fit for whatever reason.

This proved to work very well. I think many developers and technical users 
do the same, if they don't they should probably try it, because it really 
works well. 

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. However, the above 
argument shows why testing *is useful for real life* even in it's current 
state.

As for role of testing in the release process, I believe there is plenty of 
room to improve.
You write, biggest problem with testing is outdated packages. Yes, probably 
you are right. So, some action should be taken to overcome that. I can't 
immidiatly answer what exact actions will help, but it's a good direction 
to think on. Let's try.
So what makes package's path to testing long?
- - RC bugs. Here nothing else could be done other than fixing the bugs. 
Personally I thing that some infrastructure change could be useful here to 
force maintainers fix RC bugs. Probably any RC bug without activity for 
several (say, 5) days should "become more public", some mechanism should 
be used to encourage non-maintainers to work on the issue.
- - Complex dependency chains. Probably some scheme could be used to decrease 
the effect of those. E.g. build mostly against testing, not against sid, 
and use build-deps from sid only if relly required (what exactly "really 
required" means here, should be defined separately).
- - Arch de-sync. Can't some mix of cross-compilation and more work on 
toolchain issues improve situation here? I'm currently involved in 
dpkg-cross, and I see some interesting possibilities here.
- - What else?

> > Unless such analysis is done, almost any discussion of this topic is
> > pointless. Period.
>
> A-Ha. How long does Testing exists? And why did nobody write this paper
> in the meantime? Why do you not try to do so? I describe the facts. Not
> some imaginary proof that will never see the daylight. Period.

I don't know why nobody did such analysis. (Probably someone did? I'd love 
to read it!)
As for myself, I don't feel I understand the problem deep enough. Although 
I follow debian developent for many years, I'm only becoming to be 
involved :).
I tried to write something just now, see above. I may try deeper analysis 
later, however someone with better understanding of details could do that 
better.

> > But such analysis should be done *after* *sarge* *release*. Flaming
> > now will only postpone the release and do nothing more.
>
> As described before, it is too late to stop this discussion.

Just take action on some RC issue before you write next message to this 
flamewar :). If everybody does that way, having such a flamewar will be 
the most effective BSP in Debian's history :).

To be honest with myself, before writing this mail I've looked through the 
list of current RC bugs, found one that was last posted long ago, and 
submitted some information there that is probably enough to resolve the 
issue. That was bug #274873.


> But many maintainers simply do not care much
> about testing, Unstable runs fine for them.

Do you really think that this is the point? Do you have statistics?

My feeling is that many more maintainers don't take care much about their 
packages, and testing/sid issue has nothing with this. We have currently 
at least hundred of thousands of bugs open. Say, half of those are 
wishlists and probably shouldn't count, but the rest 50,000 are issues 
that require action! Many are open for months and years.

Nikita
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBfA3bv3x5OskTLdsRAu/wAJwOkabMCf7xca0sB5RFEaxPCKverQCgvM9i
HWrXyk6RkAFJhhxenNi3pLk=
=R+6W
-END PGP SIGNATURE-

Re: Drop testing

[Andrew M.A. Cater]

On Sun, Oct 24, 2004 at 08:44:47PM +0200, Gergely Nagy wrote:

> 
> 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
> surely find something else that "more fun": it's not "release or
> uploads", it's "release or uploads or something else". Those who do not
> give a damn about the release, will not change their mind when unstable
> is frozen.
> 
> Motivating people means getting them interested in the release, making
> the process "more fun" for them. Or at least less of a nuiseance.
> Freezing unstable will add to the annoyance level, instead of taking
> away from it.

> 
> What you propose places even more burden on the release managers, even
> more stuff to deal with. They will not get motivated by this, not at
> all. Ways to make the current system better - THAT would be very
> welcome. Like enhancing the logic of the testing scripts, which decide
> when and how a package migrates from unstable to testing, so migrations
> could get faster and large blocking stuff could be eliminated, that
> would help the release. Placing burden on people who already have more
> than enough to care and worry about won't help at all, methinks.
> 

> So far, the main complaint against testing is that sometimes packages
> get stuck. *Duh*, so fix the problem that made them stuck. That might
> need some social engineereing, as most of the time, stuckage is not
> caused by technical problems. Would you want to push the same larger
> update into a frozen unstable, you'd run into the very same problems
> anyway.
> 

All of the above makes a very great deal of sense.  I've been around
Debian as a lurker since 1.2 and an active user since 1.3.  Testing
has solved lots of problems.  Stable is _always_ too old after about two
months after release - though point releases do help when they are
allowed to be  made.  Unstable is generally just a fraction too dynamic:
I run unstable on my machines at home because I can fix it - and because 
it's not mission-critical here - but I run testing at work because it's 
had the bugs gradually hammered out of it.  I'm _hoping_ that testing will
get released Real Soon Now so that I can reassure the authorities at
work that the software is stable - it's only a name but a world of
difference and it means I can pass control of one machine to the end
users {B-)  Most users in the Linux User Group that I'm part of 
have aaparently also gradually moved to Debian testing - it works for 
them and various of them have adopted it as they have seen others succeed.

As far as _I'm_ concerned, testing is ready to release as Stable now, modulo 
one or two annoying bugs in the Sparc debian-installer.  On i386 installer 
works fine, on Alpha it's OK.  The installer is pretty much hammered to death
for all architectures.  Testing proposed updates is in place.  If we
just chucked the release out of the door tomorrow as Stable, we'd probably be
at least as ready as we were for hamm/potato/woody IMHO. This is not
insuperable. Debian advocacy is taking up quite a lot of my time at
work, to my boss's annoyance, as I point out that the commercial
distributions don't have the software we need and use :)  Dropping
testing altogether seems at first sight to be an easy option and testing
seems to be an easy target - but it benefits us much more than it hurts.

Now, fresh from flamewars, Ubuntu bashing and threats of GR's - how
close are we to release and can we just f* well do it please??

Andy

Re: Drop testing

[Joey Hess]

Eduard Bloch wrote:
> #include 
> * 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
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's
> 
> a) The release time would be shorter

Proposing a change that will tend to making it harder to have most
packages up-to-date, and then justifying it by saying you hope your
scheme will result in a shorter release time does not seem very wise to
me.

> b) It would be up to humans (and not some obscure scripts) to decide
> whether the bugs deseves a fix or not

No, I'm talking about changes made to frozen packages. Currently these
are added to testing based on human discretion, not via scripts, just as
they would be under your proposal.

> > currently frozen in testing, the situation is exactly what it is now;
> > the maintainer and RM have to decide whether putting this fix into
> > testing (or frozen) and possibly introducing new, more important bugs is
> > warrented by the ugliness of the bug. If the package is one of the large
> > majority of packages that are _not_ currently frozen in testing, then it
> 
> "not currently"? 

Currently only base packages are frozen in testing. If you don't know
this, well..

> In my solution, the whole Sid archive would be frozen.
> And there will be no Testing, see subject.

It seems to me that you have misunderstood my question. Or I do not
understand your reply. The reason I refer to testing in my question in
because I am comparing how things work _now_ with how you propose things
work.

Having a hard time making any sense of what you're saying now; if I
cannot understand your proposal, I will have to object to it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Drop testing

[Gergely Nagy]

> > >  - 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 fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution. I, for one, wouldn't run unstable on my
> > parents' box, whereas testing proved to be quite reliable there.
> 
> 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

That takes some effort, especially when the new version in unstable
build-depends something bigger (I remember how hard it was to backport
some debhelper-using stuff without backporting all of perl - I do not
want to backport large pieces of unstable).

I do not have the time and energy to do those backports. Nor do I want
to upgrade half the system, nor is any security support for backports as
far as I know. Not officially, that's certain. (Yes, there isn't one for
testing either, but most of the case I can just grab the new package
from unstable and be done with it, while it's not that easy using
backports).

And even if I could do it theoretically, J Random User who is running
testing (because stable is too old) would not be able to do the
backports himself, whenever he needs something that is not backported
already.

>  - 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 are motivated
>if Unstable is blocked and they must care about the release instead
>of working on stuff that makes "more fun".

No, they are NOT motivated if unstable is frozen. Did we get potato out
sooner than sarge? I don't think so (I may be wrong, though, it was
quite some time ago, and I was only lurking on the lists back then).

I do remember though, that I, as a mere mortal user was very upset about
unstable being frozen. I was running it to get the latest and greatest
software to play with, and when that excitement was taken away I felt a
bit cheated. You take away the toy, and whoever played with it, will
find another one, and since he's angry at you, probably not the
replacement toy you offer. (Ie, freeze unstable and I'm sure to go and
ignore Debian until there's a release - not that I do anything for the
release anyway, so it probably wouldn't matter, but still)

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
surely find something else that "more fun": it's not "release or
uploads", it's "release or uploads or something else". Those who do not
give a damn about the release, will not change their mind when unstable
is frozen.

Motivating people means getting them interested in the release, making
the process "more fun" for them. Or at least less of a nuiseance.
Freezing unstable will add to the annoyance level, instead of taking
away from it.

> > Freezing unstable will get you nothing compared to what we have now.
> 
> What do we have? Release times reaching eternity? Testing, full of
> hidden / obscure bugs that have not been visible in Sid, or that are
> fixed in Sid but the update got stuck somewhere?

So you propose that those hidden / obscure bugs will only surface when
stable comes out, because there was no testing where they could be
observed earlier? How, pray tell, is that better? How was potato's
release any better than today? Except that the arches had to be kept in
sync "manually", without the help of testing.

For updates, that are important enough but got stuck, there is
testing-proposed-updates. Once there are (security or other)
autobuilders for testing, one uploads a package there, it gets approved,
everyone's happy. Little more work on the maintainer's part, but you'd
have to do roughly the same, would unstable get frozen. With the
additional burden on the release managers that they would need to check
EVERY proposed upload. Now they only need to check a smaller amount of
uploads, since unstable - and even some parts of testing - are open
still.

What you propose places even more burden on the release managers, even
more stuff to deal with. They will not get motivated by this, not at
all. Ways to make the cur

Re: Drop testing

[Anthony Towns]

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 on
the 15th of August. The freeze itself had originally been planned for
sometime late 1999, but was put on hold a couple of times.

version   codename   freeze-daterelease-date development/freeze

 1.1   buzz  ?  1996/06/17
 1.2   rex   ?  1996/12/12  6 months
 1.3   bo?  1997/06/05  6 months
 2.0   hamm   1998/02?  1998/07/23 8 + 6 = 14 months
 2.1   slink 1998/11/03 1999/03/10 4 + 4 =  8 months
 2.2   potato2000/01/16 2000/08/1510 + 7 = 17 months
 3.0   woody 2002/05/01 2002/07/2020 + 3 = 23 months
  ?sarge ? >2004/10/20>27 months

As far as test cycles are concerned, Richard proposed them on 1999/12/28,
with the first one scheduled for 2000/01/22, hoping that two would be
needed. Test cycle one began 2000/05/02 and ended with test cycle two.
Test cycle two began 2000/05/30 and ended 2000/06/24. Test cycle three
began 2000/07/06 and ended with the release, more or less. The start
of the test cycles were delayed due to boot-floppies not being ready,
and consisted of some "bug horizons", and other miscellania. Note that
for the entire period from January to August, _no_ packages were added
or updated in potato without inspection by the release manager; with
new features and non-RC bug fixes generally being immediately rejected.
That's where the feeling that stable is 7 months out of date before it's
even release comes from.

For hamm, slink and potato, we needed to spend around 43% of our time
frozen, working solely on fixing RC bugs. "Three one-month test cycles"
simply isn't an accurate summary of what freezing Debian entails.

YMMV on the woody "freeze" date; I'm choosing the date when britney stopped
running, but it's also worth considering packages that were uploaded but
"blocked" for various reasons, and updates that weren't uploaded because
we were trying to release.

Note that when considering the latter, updates for potato were also
"discouraged" for a month or two before the actual freeze; see [0], eg.
At present, the only packages not automatically propogating to testing
are packages in base. Even things as large as Gnome 2.6 have made it
into testing since May.

I'm tempted to say "What, then, are our choices? Note that `Release every
six months, at absolutely no cost' isn't one of them", but actually it
is: we can just grab whatever the Ubuntu guys put out and stick it in
our archive, at so close to zero cost as to be indistinguishable. That's
not quite a "Debian stable release", however -- it doesn't support as
many packages, or as many architectures; so maybe there is a cost even
then.

But "freeze, sweat blood fixing bugs, release" isn't a magic formula:
it results in spending over 40% of our time sweating blood rather than
doing fun stuff, and it still takes ages to actually do, given the size
of the distribution we have. And the freeze period is usually spent
screwing up unstable completely too, which creates yet more work for
the next time round (because everyone's testing frozen, bugs in unstable
get left to sit there for months, which makes them harder to fix because
whoever was working on them forgets, or moves on).

Note that warty/main is about 1/17th the size of Debian (which probably
underestimates the difference in complexity, if complexity isn't a linear
function of size), and that, conservatively, it has probably a hundred
times the direct funding Debian has -- though Debian might well surpass
Ubuntu if you also count indirect funding, but I've no idea how you'd
manage that.

Of course, the other problem with talk of a Debian freeze is finding
someone willing to manage it -- the last freeze we had was potato,
which managed to fairly thoroughly burn out Richard Braakman, and I
think we're something like four times bigger now than we were then,
just counting packages; another factor of two if you count architectures
(aiming for a factor of three).

Cheers,
aj

[0] http://lists.debian.org/debian-devel-announce/1999/11/msg0.html

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Anthony Towns]

On Sun, Oct 24, 2004 at 03:53:23PM +0400, Nikita V. Youshchenko wrote:
> > #include 
> 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 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
* How can these be solved?
   (a) (1) Pro-active removals by release managers,
   (2) More bug fixing in unstable
   (3) Bug fixing specifically for testing
   (b) (1) Developing a maintainable installer
   (c) (1) Doing security updates for testing
   (2) Doing better security updates in unstable, 
and getting them into testing quickly

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?

> One such analysis is done and made public, most likely a
> solution will be found that is much less radical than killing everything,

Non-radical solutions don't let you write a general resolution, however.

> But such analysis should be done *after* *sarge* *release*. Flaming now will
> only postpone the release and do nothing more.

For comparison, testing was designed during a flamewar a month or two
before hamm's release. Well, extensive discussion is a far more accurate
description than flamewar -- in particular, I don't believe there was any
blame involved, whether on a person, process or tool. I may be mistaken.
Of course, there was pretty much nothing unconventional about our release
process at the time.

> Probably there are non-technical problems with the uncoming release. But
> there are technical problems also, yes? Why not eliminate those? If instead
> of each mail in this thread a single RC bug that affects sarge was fixed,
> probably there could be *zero* such bugs now.

Why not do both? Every time you post a mail to a thread like this, fix an
RC bug. This is the "ObBug:" rule.

ObBug: 275585

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Eduard Bloch]

#include 
* 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, except when the bug
> is a /really/ severe one (severity grave or critical).

Counter example: you fix a bug in Sid but insufficiently (and you do not
know for sure). Few users continue reporting bugs in the Testing
version. You ask them to test the Sid version. But Sid scares them and
they promise to wait for the update to be in Sid. Then, you will wait
weeks for the acknoledgement and the bug may still be in Testing in this
time. And it will take another two weeks for a real fix to slip into
Testing.

That is not fun. That is overhead which creates confusion.

Regards,
Eduard.
-- 
In the beginning was the word, and the word was content-type: text/plain

Re: Drop testing

[Eduard Bloch]

#include 
* 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 the fact that most developers will probably
> spend their time on item w (which is probably not a Debian task), which

At least they won't poison Sid with fresh things that may others life
more difficult. Eg. new library versions.

> they like less than x but still more than y. So this will at least fail,
> and probably hurt debian too.

Maybe. What is the alternative? Continue with the current method and
release Edge... 2009 or so?

Regards,
Eduard.
-- 
Everything is illusion. Constructs of language, light, metaphor; nothing
is real.  -- Babylon 5, Season 4

Re: Drop testing

[Eduard Bloch]

#include 
* 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
> > buggy stable release. Just face it.
> 
> AIUI, you propose to freeze unstable and go back to the old method of
> having updates during the freeze be manually put in at the discretion of
> the Release Managers. If we did that, how would one of these "ugly bugs"
> be any more likely to be fixed in frozen unstable than it is in today's

a) The release time would be shorter
b) It would be up to humans (and not some obscure scripts) to decide whether 
the bugs deseves a fix or not

Yes, some manpower would be required for this process. But fellow
maintainers could be involved into process of evulation of the quality
of a proposed upgrade.

> currently frozen in testing, the situation is exactly what it is now;
> the maintainer and RM have to decide whether putting this fix into
> testing (or frozen) and possibly introducing new, more important bugs is
> warrented by the ugliness of the bug. If the package is one of the large
> majority of packages that are _not_ currently frozen in testing, then it

"not currently"? In my solution, the whole Sid archive would be frozen.
And there will be no Testing, see subject.

Regards,
Eduard.
-- 
For any stupid thing chosen at random, you'll find at least 5 people on
the Internet who thinks it's a good idea. -- Steve Langasek in debian-devel

Re: Drop testing

[Eduard Bloch]

#include 
* 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.
> 
> You _are_ aware that this is approximately how it was done before woody, no?

Similar to those and more aggressive. Didn't I write this already?

Regards,
Eduard.
-- 
Junggesellen sollten hohe Steuern zahlen. Es ist nicht gerecht, daß
einige Männer glücklicher sein sollen als andere.
-- Oscar Wilde

Re: Drop testing

[Eduard Bloch]

#include 
* 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 this would result in many users who currently run testing fall
> back to stable + backports or switch to another distro (ubuntu being a
> likely candidate), which in turn, would result in less bugreports and a
> less stable distribution. I, for one, wouldn't run unstable on my
> parents' box, whereas testing proved to be quite reliable there.

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
 - 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 are motivated
   if Unstable is blocked and they must care about the release instead
   of working on stuff that makes "more fun".

> Freezing unstable will get you nothing compared to what we have now.

What do we have? Release times reaching eternity? Testing, full of
hidden / obscure bugs that have not been visible in Sid, or that are
fixed in Sid but the update got stuck somewhere?

> Those who don't care about a release, will not care that way either,
> just their complaints will get louder and more frequent. Those who are

How should they complain? "We cannot update foo in Sid because it has
been frozen for three weeks now, nya, nya". The answer would be some
analogue to RTFM (HTFR, help the f... release).

> willing to do the work neccessary for the release are already trying to

Re: Drop testing

[Eduard Bloch]

#include 
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > #include 
> 
> 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.

> 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. One such analysis is done and made public, most likely a
> solution will be found that is much less radical than killing everything,
> and still eliminate the problems, or make the problems smaller.
> 
> Unless such analysis is done, almost any discussion of this topic is
> pointless. Period.

A-Ha. How long does Testing exists? And why did nobody write this paper
in the meantime? Why do you not try to do so? I describe the facts. Not
some imaginary proof that will never see the daylight. Period.

> But such analysis should be done *after* *sarge* *release*. Flaming now will
> only postpone the release and do nothing more.

As described before, it is too late to stop this discussion.

> 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 comes?

> of each mail in this thread a single RC bug that affects sarge was fixed,
> probably there could be *zero* such bugs now.

If we would fix the bugs in the distribution that is to be released,
there would be *zero* now. But many maintainers simply do not care much
about testing, Unstable runs fine for them. That is why a refered Joel
on Software, RTF paper. Please.

Regards,
Eduard.
-- 
Wie man sein Kind nicht nennen sollte: 
  Flora Soft 

Re: Drop testing

[Nikita V. Youshchenko]

> #include 

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-less analysis of each problem
and it's reasons. One such analysis is done and made public, most likely a
solution will be found that is much less radical than killing everything,
and still eliminate the problems, or make the problems smaller.

Unless such analysis is done, almost any discussion of this topic is
pointless. Period.

But such analysis should be done *after* *sarge* *release*. Flaming now will
only postpone the release and do nothing more.

Probably there are non-technical problems with the uncoming release. But
there are technical problems also, yes? Why not eliminate those? If instead
of each mail in this thread a single RC bug that affects sarge was fixed,
probably there could be *zero* such bugs now.

Re: Drop testing

[Wouter Verhelst]

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 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 fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.
> 
> 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, except when the bug
is a /really/ severe one (severity grave or critical).

When this is true, it doesn't matter whether the user is a testing one
or an unstable one -- both packages simply are of the same version.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Drop testing

[Martin Schulze]

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 work instead of wasting time on
> >synching stuff. This eliminates the need for testing-security. See
> >the last part of the paper for details.
> 
> 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?

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

Please always Cc to me when replying to me on the lists.

Re: Drop testing

[Joey Hess]

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 are a disaster, they make
> our definition of a Stable release absurd. Yes, Debian Stable has become a
> buggy stable release. Just face it.

AIUI, you propose to freeze unstable and go back to the old method of
having updates during the freeze be manually put in at the discretion of
the Release Managers. If we did that, how would one of these "ugly bugs"
be any more likely to be fixed in frozen unstable than it is in today's
partially frozen testing? If it were a bug on one of the packages
currently frozen in testing, the situation is exactly what it is now;
the maintainer and RM have to decide whether putting this fix into
testing (or frozen) and possibly introducing new, more important bugs is
warrented by the ugliness of the bug. If the package is one of the large
majority of packages that are _not_ currently frozen in testing, then it
seems it would be harder to get it into frozen using your proposed
method than it is to get it into testing now.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Drop testing

[Brian Nelson]

On Sat, Oct 23, 2004 at 03:52:51PM -0700, Steve Langasek wrote:
> 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 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 fall
> > > back to stable + backports or switch to another distro (ubuntu being a
> > > likely candidate), which in turn, would result in less bugreports and a
> > > less stable distribution.
> 
> > 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.
> 
> This seems like a rather unsubstantiated claim.  Do you *know* how many of
> the good bug reports you've seen come from users of testing vs. unstable?

I don't have any hard data, but I've been tracking debian-bugs-dist for
about 2 years now so I think I have a decent feel for it.  True, you
can't always be sure if the user is using testing or unstable, but it
often can be inferred.

[...]
> Yes, filing bug reports on testing is not often useful (except during a
> freeze), but that's not the same as it not being useful to have users
> running testing.

I didn't claim otherwise.  I was just trying to refute the claim that
bug reports from testing users were useful.

I do question if having testing available to the public throughout the
entire release cycle is actually beneficial to the community.  There's a
common misconception in the community that testing is a "more stable"
unstable.  Many testing users aren't even aware that testing doesn't
have security updates.  Probably most of the users of testing should
*not* be using it at all.  This isn't really related to the proposal in
this thread to just drop testing though.

-- 
Blast you and your estrogenical treachery!

Re: Drop testing

[Steve Langasek]

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 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 fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.

> 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.

This seems like a rather unsubstantiated claim.  Do you *know* how many of
the good bug reports you've seen come from users of testing vs. unstable?
Reportbug should give this kind of information, but just looking at the
version of the package they've filed the bug against isn't even an
indicator; it may just mean the user tried upgrading to the unstable version
of the package before reporting the bug, because she was trying to ensure
the bug report would be useful/was hoping the bug was fixed without any need
to file a bug report.

Yes, filing bug reports on testing is not often useful (except during a
freeze), but that's not the same as it not being useful to have users
running testing.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Drop testing

[Matthias Urlichs]

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* dependency problem easily, but you can fix the *next*
one, by telling the maintainers in question that they should be somewhat
more careful.   Plus, if there was no Testing, the transient problem
may well become a semi-permanent one. 

As for reporting bugs fixed in Unstable: presumably, after Sarge there
will be a version-aware BTS for Debian, so that the person using Testing
will still see the bug report and thus can upgrade that package from
Unstable; apt-preferences are your friend. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Drop testing

[Brian Nelson]

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. 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 fall
> back to stable + backports or switch to another distro (ubuntu being a
> likely candidate), which in turn, would result in less bugreports and a
> less stable distribution.

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.

-- 
Blast you and your estrogenical treachery!

Re: Drop testing

[Jose Carlos Garcia Sogo]

El sÃb, 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 the "filtering updates for frozen" - yes, some additional
>manpower is required but that work must be done. The problems with
>Testing synchronisation are not of pure technical nature, they are
>social problem, and so they should be solved by people and not
>scripts.

 Perhaps there is another approach, combining both the benefits of
having testing and of freezing. But this means having a time based
release timeline. And this is something that it is not being discussed
here, but also Ubuntu can be released because they have a timeline, what
makes people rush a bit for what they want. Of course Ubuntu has paid
people for doing tasks, but Debian can permit dropping some packages in
one release if they're not ready, as we don't sell a product.

 From a mail in  debian-custom[1] with a little fix:
 

8.6 New way to distribute Debian

Here is my own proposal for these, I think every Debian developer/user
has his very own one:

* During "normal" debian developer cycle (from T0 to T0 + 1 year):
DD -> unstable -> testing
QA -> security -> stable

at T0 + 1 year:
freeze := testing

* During "freeze" ( from T0 + 1 year to T0 + 1.5 year ):

 DD -> unstable -> testing
DD + QA -> freeze -> stable

at T0 + 1.5 years = T1:
stable := freeze
old-stable := stable (security for 6 months, already done by QA)


 Of couse, timeline can be adjusted, and I think that a 2 month freeze
should be enouogh, but what I want to show is how both testing and
freeze could be used together. 

 Regards,

[1] http://lists.debian.org/debian-custom/2004/09/msg00033.html 

-- 
Jose Carlos Garcia Sogo
   [EMAIL PROTECTED]


signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente

Re: Drop testing

[Gergely Nagy]

> 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-security. See
>the last part of the paper for details.

Doing this would result in many users who currently run testing fall
back to stable + backports or switch to another distro (ubuntu being a
likely candidate), which in turn, would result in less bugreports and a
less stable distribution. I, for one, wouldn't run unstable on my
parents' box, whereas testing proved to be quite reliable there.

Freezing unstable will get you nothing compared to what we have now.
Those who don't care about a release, will not care that way either,
just their complaints will get louder and more frequent. Those who are
willing to do the work neccessary for the release are already trying to.

Remember, Debian is a volunteer project, you cannot force people to do
something they do not want to.

>  - about the "filtering updates for frozen" - yes, some additional
>manpower is required but that work must be done. The problems with
>Testing synchronisation are not of pure technical nature, they are
>social problem, and so they should be solved by people and not
>scripts.

Yes, testing synchronisation is not a purely technical matter. Nor is it
purely social, so the testing scripts, which automatically keep stuff in
sync, are a real help. On top of that, package maintainers coordinating
with each other (the social part) is welcomed too, and should be
encouraged. (And those who break a transition should be kicked in the
ass, so they won't try it again :P)

I firmly believe that fixing the problems with testing (mainly
testing-security at this point in time) would be MUCH better than
dropping testing and freezing unstable before the next release.

-- 
Gergely Nagy

Re: Drop testing

[Steinar H. Gunderson]

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 on
>synching stuff. This eliminates the need for testing-security. See
>the last part of the paper for details.

You _are_ aware that this is approximately how it was done before woody, no?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: Drop testing

[Marco d'Itri]

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 (which is probably not a Debian task), which
they like less than x but still more than y. So this will at least fail,
and probably hurt debian too.

-- 
ciao, |
Marco | [8706 imssHyI9cD64A]


signature.asc
Description: Digital signature

Drop testing

[Eduard Bloch]

#include 

> > Some improvements have already been proposed by Eduard Bloch and
> > Adrian Bunk: freezing unstable while keeping testing.
> 
> Jerome, please, you could have asked me. I prepare an internal GR draft
> for exactly this issue, but it is to be made public on the day of the
> release, and better not before. We should concentrate on making the
> Sarge release ready, NOW. Do not start another flamewar.

To hell with it, the avalanche has already started.

The attached paper was written down as a GR draft, but if the problem
can be solved peacefully by a consens on d-d 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 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 the "filtering updates for frozen" - yes, some additional
   manpower is required but that work must be done. The problems with
   Testing synchronisation are not of pure technical nature, they are
   social problem, and so they should be solved by people and not
   scripts.

Regards,
Eduard.
-- 
Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei
Katzen.
-- Sprichwort
ABSTRACT


I propose that the Debian project resolve these questions:

 - should we continue using Testing and the gradual freeze model?
 - should we change the freeze model to the tristate model (similar to the one
   from the old days)

Possible choices:

 - stop using Testing distribution and change to the Tristate freeze model
 - stop using Testing, the release manager should develop the freeze model
 - continue using the current release model

RATIONALE
-

Why is testing bad?
==

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 in
the past years that testing created more problems that it was really worth.

The only advantages guaranteed by its structure was a promise to keep an
installable set of packages. Which does not promise a useful/bugfree piece
of software. I think we should be fair to our users when we tell them to
report bugs - we should tell all of them that reporting bugs in Sarge is
often duplicated work because the problem has been fixed in Unstable.  I
think we should be fair to our users - we should not put a lot of buggy
software onto their heads (promising some bogus stability at the same time),
without having working security upgrade system. Without giving the
individual developer a chance to fix bugs in the development distribution
quickly enough. Without having automatic ways to integrate an update into
every arch in the Debian distribution.

Some words about the history


Some years ago and before almost a half of developers joined, Testing did
not exist in its current form. Instead, the release cycle worked differently
(see below). At some time point, the RM of those days decided to make an
experiment, which resulted in what we call Testing now. In the years before,
the Freeze was a real freeze (not the ice sludge we have today). Unstable
was frozen as-is and stayed in this state untill the RC bug count was down
to zero. It was not worse than what we have today: Frozen got its own
release branch name, deliberate uploads to Frozen could be detected easy and
inspected by the RM. Almost the same work that is done now by the RM team.
But OTOH the developers had to eat the dog food [1] and there were no stupid
overhead required to move packages to Testing, working around obscure
problems.

How does the situation look today?
==

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 are a disaster, they make
our definition of a Stable release absurd. Yes, Debian Stable has become a
buggy stable release. Just face it.
The major goal (making Freeze periods shorter) was not reached. The second
goal (faster releases) was not reached. The third goal (better software
quality in the development branch) was not reached, at most partially (the
users did not have to deal with PAM bugs this time, hahaha).

So in my eyes, the Testing experiment failed and should be finished. Now.

So how would the removal of Testing help?
=

 - there would be no obscure criteria that te