Debian Bug report logs - #484129
release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion

Package: release.debian.org; Maintainer for release.debian.org is Debian Release Team <debian-release@lists.debian.org>;

Reported by: Raphael Hertzog <hertzog@debian.org>

Date: Mon, 2 Jun 2008 16:30:02 UTC

Severity: wishlist

Done: Julien Cristau <jcristau@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 02 Jun 2008 18:27:08 +0200
Package: release.debian.org
Severity: wishlist

Following a quick chat with Luk, and following the discussion in #484009
about the removal of update-notifier/update-manager, I want to make the
following suggestions:

- the release team should encourage volunteers to fix in priority RC bugs
  that matters more first. This includes bugs in packages of priority >=
  standard, non-leaf packages and leaf packages which are listed in one or
  more tasks (cf tasksel git repo for the latest version of tasks:
  http://git.debian.org/?p=tasksel/tasksel.git;a=tree;f=tasks;hb=HEAD )

  This could be done by adding a restricted view of
  http://bts.turmzimmer.net/ or
  http://bugs.debian.org/release-critical/

  This can also be done by providing a listing a affected packages in
  the regular news sent to debian-devel-announce.

- the release team should only remove packages listed in tasks after
  having explicitely warned the maintainer concerned. Such mails should
  be CCed to debian-devel so that other volunteers can jump in and take
  over the work of the MIA maintainer (and also give their opinion if
  the package should instead be dropped from the task as it's no more
  suited). A delay of one week would seem reasonable and wouldn't change
  much when those packages are only removed after long periods
  of inactivity in the bug log.

I think it's important that the release team supports the work done on
tasksel (by the d-i team) by not removing unilateraly packages which are
listed in tasks. They have been added there in the first place for a
reason, it would be nice to be able to offer a continued user experience
from release to release and not have significant functionalities
disappear just because we (as Debian, not as release team) have not been
able to recruit volunteers for the corresponding packages.

Thank you for your consideration and for your work!

Cheers,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb@yosemite.net>
To: debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 10:20:25 -0700
On Mon June 2 2008 09:27:08 Raphael Hertzog wrote:
> I think it's important that the release team supports the work done on
> tasksel (by the d-i team) by not removing unilateraly packages which are
> listed in tasks. They have been added there in the first place for a
> reason, it would be nice to be able to offer a continued user experience
> from release to release and not have significant functionalities
> disappear just because we (as Debian, not as release team) have not been
> able to recruit volunteers for the corresponding packages.

A good idea but it doesn't go far enough.  Personally I don't find
d-i tasks to be any more important than "the packages I need", and
I suspect millions of Debian users have equivalent opinions.

Packages are summarily removed from Testing far too often, and then
find it much harder to return because they are then "new".  I don't
know if the algorithms were changed six months ago, but starting
around the turn of the year we've frequently had to resort to Sid
when replicating existing configurations onto new boxes.  This is a
bar to adoption by new users, and new users are usually desktop or
laptop users who need Testing for hardware support.

Artificially lowering the RC count in Testing is not always
preferential to keeping Testing in a state amenable to testing.

--Mike Bird




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Luk Claes <luk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 484129@bugs.debian.org (full text, mbox):

From: Luk Claes <luk@debian.org>
To: Mike Bird <mgb@yosemite.net>
Cc: debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 03 Jun 2008 04:05:38 +0200
Mike Bird wrote:
> On Mon June 2 2008 09:27:08 Raphael Hertzog wrote:
>> I think it's important that the release team supports the work done on
>> tasksel (by the d-i team) by not removing unilateraly packages which are
>> listed in tasks. They have been added there in the first place for a
>> reason, it would be nice to be able to offer a continued user experience
>> from release to release and not have significant functionalities
>> disappear just because we (as Debian, not as release team) have not been
>> able to recruit volunteers for the corresponding packages.
> 
> A good idea but it doesn't go far enough.  Personally I don't find
> d-i tasks to be any more important than "the packages I need", and
> I suspect millions of Debian users have equivalent opinions.

That's what rc-alert is for.

> Packages are summarily removed from Testing far too often, and then
> find it much harder to return because they are then "new".  I don't
> know if the algorithms were changed six months ago, but starting
> around the turn of the year we've frequently had to resort to Sid
> when replicating existing configurations onto new boxes.  This is a
> bar to adoption by new users, and new users are usually desktop or
> laptop users who need Testing for hardware support.

Accusing won't help at all, no the algorithms are not changed. Fixing RC
bugs for instance in the list you get from rc-alert might prevent your
apparently changing view...

> Artificially lowering the RC count in Testing is not always
> preferential to keeping Testing in a state amenable to testing.

You say yourself that it's not artificially as RC bugs in "new" packages
don't get that easily in testing anymore...

Cheers

Luk




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: debian-devel@lists.debian.org
Cc: 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 11:32:52 -0700
On Mon June 2 2008 19:05:38 Luk Claes wrote:
> Mike Bird wrote:
> > A good idea but it doesn't go far enough.  Personally I don't find
> > d-i tasks to be any more important than "the packages I need", and
> > I suspect millions of Debian users have equivalent opinions.
>
> That's what rc-alert is for.

You want millions of Debian users to install devscripts?  Even if they
did, how would rc-alert help them?

> > Artificially lowering the RC count in Testing is not always
> > preferential to keeping Testing in a state amenable to testing.
>
> You say yourself that it's not artificially as RC bugs in "new" packages
> don't get that easily in testing anymore...

Removing long-standing packages and stigmatizing them as "new" in order
to keep the RC count down is artificial because such packages are not
new.  It should only be done very late in the release process if the
packages are too late to be fixed for the next release.

You may regard the process as some kind of perverse incentive to DDs but
the direct consequences of Testing missing long-standing packages is to
make Testing unfriendly to newbies, annoying for experienced users, hence
less valuable for testing Debian, hence less valuable for improving Debian.

--Mike Bird




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 484129@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 20:44:46 +0200
On 02/06/08 at 11:32 -0700, Mike Bird wrote:
> On Mon June 2 2008 19:05:38 Luk Claes wrote:
> > Mike Bird wrote:
> > > A good idea but it doesn't go far enough.  Personally I don't find
> > > d-i tasks to be any more important than "the packages I need", and
> > > I suspect millions of Debian users have equivalent opinions.
> >
> > That's what rc-alert is for.
> 
> You want millions of Debian users to install devscripts?

Millions of Debian users installing devscripts, running rc-alert, and
fixing RC bugs on packages they use? Sure we want that! :-)

> > > Artificially lowering the RC count in Testing is not always
> > > preferential to keeping Testing in a state amenable to testing.
> >
> > You say yourself that it's not artificially as RC bugs in "new" packages
> > don't get that easily in testing anymore...
> 
> Removing long-standing packages and stigmatizing them as "new" in order
> to keep the RC count down is artificial because such packages are not
> new.  It should only be done very late in the release process if the
> packages are too late to be fixed for the next release.
> 
> You may regard the process as some kind of perverse incentive to DDs but
> the direct consequences of Testing missing long-standing packages is to
> make Testing unfriendly to newbies, annoying for experienced users, hence
> less valuable for testing Debian, hence less valuable for improving Debian.

See it the other way around: it shows testing the way stable could be if
nothing is done. I'm all for removing buggy packages early in the
release cycle: it makes it less likely that we release without a package
that many users need, because it was removed too late in the release
cycle, and it allow bug fixers to focus on bugs that we really,
absolutely need to fix to be able to release.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: 484129@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 13:22:28 -0700
On Mon June 2 2008 11:44:46 Lucas Nussbaum wrote:
> See it the other way around: it shows testing the way stable could be if
> nothing is done. I'm all for removing buggy packages early in the
> release cycle: it makes it less likely that we release without a package
> that many users need, because it was removed too late in the release
> cycle, and it allow bug fixers to focus on bugs that we really,
> absolutely need to fix to be able to release.

A thing is best characterized by what it does and how it
is used rather than by the name we associate with it.  For
a moment let's recall what Testing really is for most
Debian users - Testing is the "Debian Desktop Edition".
Stable works well on older hardware, particularly servers,
but it's just not usable for most desktops and laptops.

The unnecessary holes in Testing are not merely a device
to coerce DDs into fixing RC bugs.  They make Debian harder
to use, harder to test, and harder to improve.  Debian
would be better without these holes.

There are better processes for reducing RC counts and
improving Debian without crippling "Debian Desktop Edition".

--Mike Bird




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 484129@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: 484129@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 22:31:11 +0200
On Mon, Jun  2, 2008 at 13:22:28 -0700, Mike Bird wrote:

> There are better processes for reducing RC counts and
> improving Debian without crippling "Debian Desktop Edition".
> 
Thanks for sharing your experience about improving Debian.
Oh, wait...

Cheers,
Julien




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 484129@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 02 Jun 2008 23:39:01 +0200
On 11404 March 1977, Mike Bird wrote:

>> > Artificially lowering the RC count in Testing is not always
>> > preferential to keeping Testing in a state amenable to testing.
>> You say yourself that it's not artificially as RC bugs in "new" packages
>> don't get that easily in testing anymore...
> Removing long-standing packages and stigmatizing them as "new" in order
> to keep the RC count down is artificial because such packages are not
> new.  It should only be done very late in the release process if the
> packages are too late to be fixed for the next release.

> You may regard the process as some kind of perverse incentive to DDs but
> the direct consequences of Testing missing long-standing packages is to
> make Testing unfriendly to newbies, annoying for experienced users, hence
> less valuable for testing Debian, hence less valuable for improving Debian.

Feel free to work on an alternative algorithm to manage testing in a
different way, fixing what you currently dont like.

I am sure that, if you get the work done, the release team will take a
look at it.

Of course that involves actually doing the work, Im sorry for suggesting
that.

-- 
bye, Joerg
2.5 million B.C.: OOG the Open Source Caveman develops the axe and
releases it under the GPL. The axe quickly gains popularity as a means
of crushing moderators heads.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: 484129@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 15:04:27 -0700
On Mon June 2 2008 14:39:01 Joerg Jaspert wrote:
> Feel free to work on an alternative algorithm to manage testing in a
> different way, fixing what you currently dont like.
>
> I am sure that, if you get the work done, the release team will take a
> look at it.
>
> Of course that involves actually doing the work, Im sorry for suggesting
> that.

Hi Joerg,

It is my understanding that the 20-day RC removal is release
team policy implemented manually.  The steps to fix this bug
are therefore:

(1) Identify the problem [done].
(3) Offer a solution [done] - specifically - "don't create 20-day
    removal hints for packages with RC bugs except when its too
    late for a fix to be included in the forthcoming release".
(3) Persuade the maintainer (release team) to accept the solution [WIP].
   
As you can see, I am doing the work, despite obstruction and
ad hominem attacks from those who should know better.  If
there's code that needs to be updated I'll be happy to send
you a patch if you point me to the source, but my (possibly
faulty) understanding is that release team members were
generating the remove hints manually.

--Mike Bird




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 484129@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: 484129@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 3 Jun 2008 02:38:53 +0200
On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> On Mon June 2 2008 14:39:01 Joerg Jaspert wrote:
> > Feel free to work on an alternative algorithm to manage testing in a
> > different way, fixing what you currently dont like.
> >
> > I am sure that, if you get the work done, the release team will take a
> > look at it.
> >
> > Of course that involves actually doing the work, Im sorry for suggesting
> > that.
> 
> Hi Joerg,
> 
> It is my understanding that the 20-day RC removal is release
> team policy implemented manually.  The steps to fix this bug
> are therefore:
> 
> (1) Identify the problem [done].
> (3) Offer a solution [done] - specifically - "don't create 20-day
>     removal hints for packages with RC bugs except when its too
>     late for a fix to be included in the forthcoming release".
> (3) Persuade the maintainer (release team) to accept the solution [WIP].

Your proposed solution doesn't allow testing to converge to a releasable
state. The only solution you are offering is "do nothing".

How will the release team know that it's late enough to start
removing packages, if the stats are cluttered by hundreds of RC bugs
noone cares about? You have to propose a valid alternate metric
and then implement code that allows to keep track of this metric.

For example, if you provided two lists of RC bugs (those in packages
that will be removed if not fixed, and those that we need to address),
and graphs for the number of bugs in each class, maybe you could try to
convince the release team that it's useless to remove packages from
testing that early.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: 484129@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Mon, 2 Jun 2008 16:16:51 -0700
On Mon June 2 2008 17:38:53 Lucas Nussbaum wrote:
> On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> > "Don't create 20-day removal hints for packages with RC bugs
> > except when its too late for a fix to be included in the
> > forthcoming release". 
>
> Your proposed solution doesn't allow testing to converge to a releasable
> state. The only solution you are offering is "do nothing".

Lucas,

The current 20-day policy only applies to "leaf" packages.  I don't
know which definition of "leaf" is intended, so let's assume that
it refers to packages referenced in Pre-Depend, Depends, and
Recommends but not Suggests, as that roughly matches aptitude's
default behavior.

Of approx[1] 21828 Lenny packages which we track, approx[1] 10514
or 48% are non-leaf and therefore excluded from the current 20-day
policy.  (If Suggests dependencies are included the latter figure
rises to 12786 or 59%).

Therefore it cannot be said that the current policy addresses the
issue you raise, as half of the packages are immune to the 20-day
rule.  There is merit to your observation, but it is a different
issue.

> How will the release team know that it's late enough to start
> removing packages, if the stats are cluttered by hundreds of RC bugs
> noone cares about?

The release team has always in the past used a process of making
DDs aware of RC bugs and RC bug counts during the release cycle,
particularly during the later stages.  The process works.  One
might wish it worked better, but at least it doesn't cripple the
"Debian Desktop Edition" for most of the release cycle.

> You have to propose a valid alternate metric and then implement
> code that allows to keep track of this metric. 

The code for the metric needs no changes.  What is needed is
to avoid distorting the metric by prematurely excluding RC
bugs from Testing and from the metric.

The RC-bugs-in-testing metric is actually a better metric for
not artificially excluding RC bugs from testing.  A better
metric gives better control of the release process.

This is a useful (but unintended) side-effect.  The principal
goal remains that Testing should be usable for new desktop
installations for most of the release cycle.

> For example, if you provided two lists of RC bugs (those in packages
> that will be removed if not fixed, and those that we need to address),
> and graphs for the number of bugs in each class, maybe you could try to
> convince the release team that it's useless to remove packages from
> testing that early.

There is a single list of RC bugs which, if not excused, cause
packages to be excluded from the final release.  I see no reason
to change this.

--Mike Bird

[1] These figures are approximate because we include a few packages
    from unofficial sources and we exclude a few Debian packages.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: 484129@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 03 Jun 2008 11:22:45 +0200
[Message part 1 (text/plain, inline)]
On Mon, Jun 02, 2008 at 11:16:51PM +0000, Mike Bird wrote:
> On Mon June 2 2008 17:38:53 Lucas Nussbaum wrote:
> > On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> > > "Don't create 20-day removal hints for packages with RC bugs
> > > except when its too late for a fix to be included in the
> > > forthcoming release". 
> >
> > Your proposed solution doesn't allow testing to converge to a releasable
> > state. The only solution you are offering is "do nothing".
> 
> Lucas,
> 
> The current 20-day policy only applies to "leaf" packages.  I don't
> know which definition of "leaf" is intended, so let's assume that
> it refers to packages referenced in Pre-Depend, Depends, and
> Recommends but not Suggests, as that roughly matches aptitude's
> default behavior.

  A leaf package is a package that is not part of any {pre-,}depends
line.

> Of approx[1] 21828 Lenny packages which we track, approx[1] 10514
> or 48% are non-leaf and therefore excluded from the current 20-day
> policy.  (If Suggests dependencies are included the latter figure
> rises to 12786 or 59%).

  Actually that's wrong, because there are packages that are part of a
Depends that are leaf package for me: e.g. when a library has a unique
r-dep, it's as if it was part of this r-dep and I consider it leaf. But
that's almost nitpicking.

  Also there are a few packages that wont be removed that way, because
it would too hard to make them enter testing again (I assume iceweasel
is a leaf package, it's already hard to make it transition usually,
let's do not remove it). But those exceptions are few, and must be,
because those have to be special cased and it doesn't scale.

> The RC-bugs-in-testing metric is actually a better metric for
> not artificially excluding RC bugs from testing.

  Why "artificially" ?

> The principal goal remains that Testing should be usable for new
> desktop installations for most of the release cycle.

  No it's not. The principal goal of testing is to evaluate what would
be our next stable if we tried to release *RIGHT NOW*. Packages with RC
bugs cannot be part of a release, so must be kept out. *I* don't really
care about testing being fully usable all the time, I care about it
being a good representation of what could be released. Testing was meant
as a release management tool, not really as a usable distribution.

  People happen to use it, but (1) I often discourage this to people I
talk to (2) there are people that care about testing being usable,
that's why testing-security and t-p-u exists. Talk to them, those are
the guys that are interested in fixing packages before we actually
remove them from testing. I work from this URL [0] (I posted it already
several times btw), there is around 100 bugs, it's quite easy to have a
look at it, and to see if there is something worth saving in the
list[1].  But that's not our job[2].


  I'd like to add a thing that you miss totally and that doesn't make
this "artificial" at all:

  * We do *NOT* remove packages that are fixed in sid and not yet in
    testing. Our job here, is to try to make packages that are fixed in
    sid and not in lenny migrate. It's a bit too soon to start that for
    each package, but it's what we work on indirectly when we work on
    transitions before the freeze.

  * We do *NOT* remove packages where the maintainer is active on the
    bug and is in the process of fixing it or at least finding out what
    is going on.

  IOW, we remove packages we cannot do anything about as Release Team
members. IOW we indeed remove packages that are Noise in the RC bugs
counts that we have to deal with. It's not a trick, it's a: we can't do
anything about those, get them out from the way, full stop.

  [0] http://bts.turmzimmer.net/details.php?bydist=both&sortby=srcpackages&ignhinted=on&ignclaimed=on&ignnew=on&ignmerged=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&new=20&refresh=1800

  [1] Note that if such a team has a real existence (like known people
      that we can possibly talk to) I wouldn't mind at all to pre-share
      what I intend to remove with them before I actually do it so that
      they can veto some removals because they will fix it *RSN* (I mean
      vetoing a removal "just because it sucks" is out of the question).
      At the time of the writing, such a team/person doesn't exist.

      Also, I'm here to remove packages, I'm also here to make a package
      that was removed enter testing again quicker if needed (as 'new'
      package in testing do not respect urgency settings, but release
      team members have the power to change that). Package maintainers
      that have had their package removed can contact us about that on
      the debian-release@ list (Of course we won't force new upstream
      releases in 2 days, but if the fix is a patch against the last
      version that was in testing, we can consider it).

  [2] it doesn't mean that there aren't any Release Team member that
      cares about testing usability. I just say that it's not really our
      "mission".
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Neil McGovern <maulkin@halon.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 484129@bugs.debian.org (full text, mbox):

From: Neil McGovern <maulkin@halon.org.uk>
To: 484129@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 3 Jun 2008 12:15:44 +0100
On Mon, Jun 02, 2008 at 04:16:51PM -0700, Mike Bird wrote:
> "Debian Desktop Edition" for most of the release cycle.
> 

There is no Debian Desktop Edition. Perhaps you mean the Debian Desktop
subproject?

> This is a useful (but unintended) side-effect.  The principal
> goal remains that Testing should be usable for new desktop
> installations for most of the release cycle.
> 

Where is it stated that this is the goal of testing?

Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at submit@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 484129@bugs.debian.org
Cc: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 03 Jun 2008 13:31:12 +0200
[Message part 1 (text/plain, inline)]
On Mon, Jun 02, 2008 at 04:27:08PM +0000, Raphael Hertzog wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> Following a quick chat with Luk, and following the discussion in #484009
> about the removal of update-notifier/update-manager, I want to make the
> following suggestions:
> 
> - the release team should encourage volunteers to fix in priority RC bugs
>   that matters more first. This includes bugs in packages of priority >=
>   standard, non-leaf packages and leaf packages which are listed in one or
>   more tasks (cf tasksel git repo for the latest version of tasks:
>   http://git.debian.org/?p=tasksel/tasksel.git;a=tree;f=tasks;hb=HEAD )

  No, tasks are not our concern directly, as it lists many packages that
any user can live without, without being hurt or even impeded. The sole
thing that matters is the priority, but packages with high priorities
are hardly leaves packages as a general rule.

  Moreover, it's not the task of the RM team to send those updates IMHO,
we already have our hands full with transitions and so on, and there are
already many tools to do that (rc-alert, bugscan, turmzimmer and so on).

>   This can also be done by providing a listing a affected packages in
>   the regular news sent to debian-devel-announce.

  No, the list would be too long, and this information is already
publicly available.

> - the release team should only remove packages listed in tasks after
>   having explicitely warned the maintainer concerned.

  I disagree. Or yes I agree, lets do it: Maintainers that have packages
listed in tasks, and that have RC open and unanswered for 20 days, and
that are leaves packages, we WILL remove your package. Done, they have
been warned (mail to dda yesterday has this information, it's publicly
known, each maintainer receives mails for bugs, he has all information
at hand).

>   Such mails should be CCed to debian-devel so that other volunteers

  Please just don't add new administrivia. Like I said in my other mail,
if a real team (with a ML or so) wants to work on removals, then yeah
I'm okay with sending removals like 1 or 2 days in advance to that list,
and see 1 or 2 days later which packages have been worked on and have a
fix in unstable. We just can't add more administrivia than this. _again_
the targets of removals are not _that_ many and known publicly.

> I think it's important that the release team supports the work done on
> tasksel (by the d-i team) by not removing unilateraly packages which are
> listed in tasks. They have been added there in the first place for a
> reason, it would be nice to be able to offer a continued user experience
> from release to release and not have significant functionalities
> disappear just because we (as Debian, not as release team) have not been
> able to recruit volunteers for the corresponding packages.

  That's very generic, and I care more about giving our users a sane
experience with working software. Debian is about things that work. If
it doesn't, it's not shipped. Instead of the big amount of hot air that
has been moved on the subject, you could have easily "saved" 3 or 4
packages instead. We're not fighting against d-i at all on this, nor are
we fighting anyone for the matter. We're doing our job. *ANY* DD
interested in QA work and releasing has dozen of ways to get RC bugs
lists, and he can follow his own priority list here, the release team is
always happy when RC bugs are closed. Don't blame us because you don't
use rc-alert on your system and discover that packages you love are in
bad shape when it gets removed.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 484129@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 3 Jun 2008 12:42:22 -0400
[Message part 1 (text/plain, inline)]
Pierre Habouzit wrote:
>   No, tasks are not our concern directly, as it lists many packages that
> any user can live without, without being hurt or even impeded. The sole
> thing that matters is the priority, but packages with high priorities
> are hardly leaves packages as a general rule.

Tasksel is designed to continue working if not all packages in a task
are available, but at the same time most tasks have certian Key packages
which, if unavailable, will prevent the task from being used at all. The
idea is that, without those packages, the task cannot be performed at
all.

Most of these are low priority, and some (starred below) are leaf packages.
The release team should be aware of this, and should try to avoid killing
tasks by removing them unnecessarily, and should probably communicate to the
tasksel maintainers if it does need to remove them.

 language-env
*ttf-sil-abyssinica
 manpages-pt
*jfbterm
*zhcon
 console-cyrillic
 t1-cyrillic
 postgresql
 xorg
 xserver-xorg-video-all
 xserver-xorg-input-all
 desktop-base
 menu
 iceweasel
 bind9
 nfs-kernel-server
 samba
 manpages-fr
 manpages-de
 gnome-desktop-environment
 gsfonts-x11
 ttf-dejavu
 ttf-freefont
 xfonts-base
*manpages-it
 manpages-ja
*lv
 kde-core
 kdeadmin
 kdeartwork
 kdegraphics
 kdemultimedia
 kdenetwork
 kdeutils
 kdepim
 kdm
 acpid
 hibernate
 anacron
 cupsys
 cupsys-client
 cupsys-bsd
*manpages-ru
 manpages-es
*manpages-tr
 apache2-mpm-prefork
*xfce4
 gdm

Beyond tasksel, your criteria that low priority leaf packages can be removed
at any time is flawed. Another example is that d-i apt-installs a variety of
low priority leaf packages. I don't have a complete list of those.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Joey Hess <joeyh@debian.org>, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 03 Jun 2008 21:58:09 +0200
[Message part 1 (text/plain, inline)]
On Tue, Jun 03, 2008 at 04:42:22PM +0000, Joey Hess wrote:
> Pierre Habouzit wrote:
> >   No, tasks are not our concern directly, as it lists many packages that
> > any user can live without, without being hurt or even impeded. The sole
> > thing that matters is the priority, but packages with high priorities
> > are hardly leaves packages as a general rule.
> 
> Tasksel is designed to continue working if not all packages in a task
> are available, but at the same time most tasks have certian Key packages
> which, if unavailable, will prevent the task from being used at all. The
> idea is that, without those packages, the task cannot be performed at
> all.
> 
> Most of these are low priority, and some (starred below) are leaf packages.
> The release team should be aware of this, and should try to avoid killing
> tasks by removing them unnecessarily, and should probably communicate to the
> tasksel maintainers if it does need to remove them.
> 
> [...]
> *lv
> [...]
> *xfce4
> [...]
> 
> Beyond tasksel, your criteria that low priority leaf packages can be removed
> at any time is flawed. Another example is that d-i apt-installs a variety of
> low priority leaf packages. I don't have a complete list of those.

  Well in your list, there are several intersting examples. lv for
example, has many replacements. That may not have all the features of
lv, but that are a decent replacement. Moreover lv isn't _that_ known,
and if this task doesn't install lv, noone will be hurt. OTOH of course,
we won't remove xfce4.

  In my view, the release team is here to be sure the release meets a
handful of critera (non exhaustive list) being:
  * taking care of explicit release goals ;
  * taking care of having no RC bugs ;
  * taking care of non-explicit release goals.

  THe later are goals that we all pursue that are not written because
self-evident like:
  * having a working gnome/kde/xfce4, or having a recent enough
    iceweasel, or or or...
  * having a recent toolchain
  * having a recent kernel ...

  Usually those non explicit goals depends upon meta-packages like
kde-core/kde/gnome/xfce4/... And we trust maintainers of those
meta-packages to provide dependencies on the really hot stuff. And yes
you can have huge meta-package for the less used stuff. Kde used to (and
probably still have) 3 layers of meta packages: kde-core (what you
absolutely need for a small KDE), kde (for the official "KDE" branded
stuff), kde-extra or sth similar, for the third party stuff.

  I'd like to recall that all the noise started from the fact that I
removed update-notifier and friends from testing. Those packages are
hardly needed for having a great Debian Gnome experience. I'd like to
point out that:
  * update-* were leaf packages, and weren't depends from a meta
    package;
  * both Loic and Josselin agree that those packages are not in a shape
    satisfactory for release, especially since it's full of ubuntuisms
    and that it lacks many of its useful features because of that. To
    cite an example Loic told me, update-* decide that an update is a
    security one because the distribution name ends with -security,
    which is a *unbuntu* thing, and won't work for Debian. Given that
    the goals of the applet is to urge end users to apply security
    updates when it happens, well, in Debian, it totally misses the
    point.

  What happens for real, is that Raphaël made a lot of noise about a
package he really cares about, and he saw disappear from testing (and in
fact he didn't really saw it, he saw someone else talk about it). I've
seen packages I care about disappear from testing (or even from Debian
altogether), or simple be unmaintained in the past. I've usually instead
of crying, adopted them or fixed them in NMUs, or done QA uploads. You
can see in that list in no specific order: lighttpd (now in the team),
xinetd (hijacked an ITA that saw no change for 3 monts), libsrs2 (was
removed from Debian, re-uploaded and adopted), ion3-scripts (was
candidate for removal, I NMUed it), ... I just wish Raphaël would have
made the same *without* the noise. Such things happen in Debian every
day, and are normal.


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 484129@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 3 Jun 2008 16:08:07 -0400
[Message part 1 (text/plain, inline)]
Pierre Habouzit wrote:
>   Well in your list, there are several intersting examples. lv for
> example, has many replacements. That may not have all the features of
> lv, but that are a decent replacement. Moreover lv isn't _that_ known,
> and if this task doesn't install lv, noone will be hurt. OTOH of course,
> we won't remove xfce4.

In the specific example of lv, if you remove it from testing, tasksel
will decide not to use the japanese tasks.

>   Usually those non explicit goals depends upon meta-packages like
> kde-core/kde/gnome/xfce4/... And we trust maintainers of those
> meta-packages to provide dependencies on the really hot stuff.

No, as I've already demonstrated, it's much more complicated than that,
and removal of lots of leaf packages that you may not consider important
at all can affect tasksel and the installer in various ways.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Joey Hess <joeyh@debian.org>, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Tue, 03 Jun 2008 22:36:25 +0200
[Message part 1 (text/plain, inline)]
On Tue, Jun 03, 2008 at 08:08:07PM +0000, Joey Hess wrote:
> Pierre Habouzit wrote:
> >   Well in your list, there are several intersting examples. lv for
> > example, has many replacements. That may not have all the features of
> > lv, but that are a decent replacement. Moreover lv isn't _that_ known,
> > and if this task doesn't install lv, noone will be hurt. OTOH of course,
> > we won't remove xfce4.
> 
> In the specific example of lv, if you remove it from testing, tasksel
> will decide not to use the japanese tasks.
> 
> >   Usually those non explicit goals depends upon meta-packages like
> > kde-core/kde/gnome/xfce4/... And we trust maintainers of those
> > meta-packages to provide dependencies on the really hot stuff.
> 
> No, as I've already demonstrated, it's much more complicated than that,
> and removal of lots of leaf packages that you may not consider important
> at all can affect tasksel and the installer in various ways.

  Then we need something that our tools can grok so that we know about
it. Not everything has this kind of importance in taskel, but if removed
packages completely render a task unusable then we need to know about it
one way or another. I don't think britney is aware of that e.g., dak
isn't either, ...

  But we just can't block _all_ the things that are part of tasks, the
update-* example shows that not everything is central either. If at
least britney is aware of it, even if other tools that helps us to write
removal hints propose removal hints that fail, we won't break anything,
merely loose some time. And then we can integrate whichever thing that
britney uses in our other tools as well.

  I'm not really into britney, but I assume data and fabio read that ;)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 484129@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: Joey Hess <joeyh@debian.org>, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 4 Jun 2008 07:19:07 +0200
* Joey Hess (joeyh@debian.org) [080603 22:24]:
> No, as I've already demonstrated, it's much more complicated than that,
> and removal of lots of leaf packages that you may not consider important
> at all can affect tasksel and the installer in various ways.

What we should make sure then is that britney recognizes these cases,
and shows "breaking task foo" for that. Is there a reasonable way to
generate pseudo-packages "taskel-$task" that depend on all the packages
that need to be present to not break anything?



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 484129@bugs.debian.org (full text, mbox):

From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: 484009@bugs.debian.org, Pierre Habouzit <madcoder@debian.org>, 484129@bugs.debian.org
Subject: removed bugs are marked as 'obsolete'
Date: Wed, 04 Jun 2008 09:03:52 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Within their efforts to eliminate RC bugs in testing, IMHO the release
managers should not forget that removed packages are marked as
'obsolete', eg. in aptitude.

An ordinary user who uses update-* to check for updates and who installs
other packages by aptitude will notice that those became 'obsolete'. She
or he might remove them from the system, as they are no longer supported
by debian and will have to look for alternatives.

A savvy user, of course will know where to look for the developers
information and might guess that they might be returned in the not too
distant future, because he read on debian-devel that a new maintainer
was found [1]...

...but then again a geek user is not as dependent on update-* than the
ordinary user, I am concerned about [2].

Johannes

[1] http://lists.debian.org/debian-devel/2008/06/msg00049.html
[2] No. 4 of http://www.de.debian.org/social_contract

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

iD8DBQFIRj5YC1NzPRl9qEURAlo6AJ9thzfRaF/mJAU1Mw8EPFCxGBGNMACfeW1T
b5+KTRdERomPTXe69tKJd2o=
=9F6x
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
Cc: 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: removed bugs are marked as 'obsolete'
Date: Wed, 04 Jun 2008 09:59:15 +0200
[Message part 1 (text/plain, inline)]
On Wed, Jun 04, 2008 at 07:03:52AM +0000, Johannes Wiedersich wrote:
> Within their efforts to eliminate RC bugs in testing, IMHO the release
> managers should not forget that removed packages are marked as
> 'obsolete', eg. in aptitude.
> 
> An ordinary user who uses update-* to check for updates and who installs
> other packages by aptitude will notice that those became 'obsolete'. She
> or he might remove them from the system, as they are no longer supported
> by debian and will have to look for alternatives.
> 
> A savvy user, of course will know where to look for the developers
> information and might guess that they might be returned in the not too
> distant future, because he read on debian-devel that a new maintainer
> was found [1]...
> 
> ....but then again a geek user is not as dependent on update-* than the
> ordinary user, I am concerned about [2].

  Oh please... Can we move on ?

  We fully address [2]: a broken software, or an inadequate one is more
a problem to me than not having it in Debian. Debian is about quality,
not quantity.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 484129@bugs.debian.org (full text, mbox):

From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: Pierre Habouzit <madcoder@debian.org>
Cc: 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: removed bugs are marked as 'obsolete'
Date: Wed, 04 Jun 2008 11:04:01 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-06-04 09:59, Pierre Habouzit wrote:
>   We fully address [2]: a broken software, or an inadequate one is more
> a problem to me than not having it in Debian. Debian is about quality,
> not quantity.

I totally agree on that.

My point is that it is probably not a good idea to tag a piece of
software as 'obsolete', when it will quite likely reappear after a few
days.

Others have pointed out that despite the bugs, update-* was not unusable
and still useful.

Johannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRlqBC1NzPRl9qEURAjUTAJ9I199AEp74N9B8szj+hhuUpm3hwwCfcwg6
Bt0Ys6JiCSplYKo+H8VDtZs=
=cJ5f
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: 484009@bugs.debian.org
Cc: 484129@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#484009: removed bugs are marked as 'obsolete'
Date: Wed, 4 Jun 2008 02:31:22 -0700
On Wed June 4 2008 00:59:15 Pierre Habouzit wrote:
> a broken software, or an inadequate one is more a problem to
> me than not having it in Debian. Debian is about quality, not
> quantity. 

(1) Pierre thus asserts IMPERFECT PACKAGE < MISSING PACKAGE.

(2) To a user who wishes to use a working feature of an imperfect
    package, Debian is better with the imperfect package than
    without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
    This is true even if the imperfect package has an avoidable
    publicized security bug.

(3) The Debian Social Contract[1] strongly supports user empowerment,
    e.g. "We will place their interests first in our priorities."

(4) Therefore, the laudable but minor goal of reducing clutter is not
    a DSC-compatible reason for ignoring users' interests.

--Mike Bird

[1] http://www.debian.org/social_contract




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@debian.org>
To: Mike Bird <mgb-debian@yosemite.net>
Cc: 484009@bugs.debian.org, 484129@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#484009: removed bugs are marked as 'obsolete'
Date: Wed, 04 Jun 2008 15:34:46 +0200
[Message part 1 (text/plain, inline)]
On Wed, Jun 04, 2008 at 09:31:22AM +0000, Mike Bird wrote:
> On Wed June 4 2008 00:59:15 Pierre Habouzit wrote:
> > a broken software, or an inadequate one is more a problem to
> > me than not having it in Debian. Debian is about quality, not
> > quantity. 
> 
> (1) Pierre thus asserts IMPERFECT PACKAGE < MISSING PACKAGE.

  For testing yes.

> (2) To a user who wishes to use a working feature of an imperfect
>     package, Debian is better with the imperfect package than
>     without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
>     This is true even if the imperfect package has an avoidable
>     publicized security bug.

  This user should use unstable.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #130 received at 484129@bugs.debian.org (full text, mbox):

From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: debian-devel@lists.debian.org, 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 04 Jun 2008 16:11:51 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-06-03 19:59, Pierre Habouzit wrote:
>   It depends of your definition of usable. I don't think it's usable on
> a daily basis because:

FWIW, let the users decide what they use or want to use. I took a curde
estimate by counting what the readers of d-u use [1].

[etch|stable] and [testing|lenny] occur in about the same number of emails.

[sid|unstable] occur in about half as many E-mails.

My conclusion: please take testing users more seriously as users. There
are a lot of them out there and that's a good thing!

Arguments like

On 2008-06-04 15:34, Pierre Habouzit wrote:
>> (2) To a user who wishes to use a working feature of an imperfect
>>     package, Debian is better with the imperfect package than
>>     without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
>>     This is true even if the imperfect package has an avoidable
>>     publicized security bug.
>
>   This user should use unstable.

sound arrogant.

Thanks,

Johannes

[1] search +testing +lenny on
http://lists.debian.org/search.html
take the 1000th message as a measure how long it takes to get 1000
messages with either 'testing' or 'lenny'. Repeat for stable etch and
sid unstable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRqKnC1NzPRl9qEURAqTcAJ9LOzvY6XAQZbzPHYjmmdKsgpdvWQCfWdKD
JMo4/B2YKOMPC7urwSA27bA=
=fCWy
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #135 received at 484129@bugs.debian.org (full text, mbox):

From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: debian-devel@lists.debian.org, 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 04 Jun 2008 16:16:38 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-06-04 16:11, Johannes Wiedersich wrote:
> [1] search +testing +lenny on

The searches were performed without the '+' to have 'testing or lenny' etc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRqPFC1NzPRl9qEURAs70AJ0e2aRYU2843atotd50NitOIhs0AACfZfUL
PdGTu4/IZd7Vt6ozZL6W9xo=
=NHKA
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #140 received at 484129@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Andreas Barth <aba@not.so.argh.org>, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 4 Jun 2008 10:58:21 -0400
[Message part 1 (text/plain, inline)]
Andreas Barth wrote:
> What we should make sure then is that britney recognizes these cases,
> and shows "breaking task foo" for that. Is there a reasonable way to
> generate pseudo-packages "taskel-$task" that depend on all the packages
> that need to be present to not break anything?

You could use the information about key packages listed in
/usr/share/tasksel/debian-tasks.desc

However, there is no equivilant source of information for packages
apt-installed by d-i.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Pierre Habouzit <madcoder@artemis.madism.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #145 received at 484129@bugs.debian.org (full text, mbox):

From: Pierre Habouzit <madcoder@artemis.madism.org>
To: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>, 484009@bugs.debian.org
Cc: debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 04 Jun 2008 18:36:07 +0200
[Message part 1 (text/plain, inline)]
On Wed, Jun 04, 2008 at 02:11:51PM +0000, Johannes Wiedersich wrote:
> Arguments like
> 
> On 2008-06-04 15:34, Pierre Habouzit wrote:
> >> (2) To a user who wishes to use a working feature of an imperfect
> >>     package, Debian is better with the imperfect package than
> >>     without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
> >>     This is true even if the imperfect package has an avoidable
> >>     publicized security bug.
> >
> >   This user should use unstable.
> 
> sound arrogant.

  No it's not. A user that prefers to have broken software rather than
no software (if the option "non broken" software is absent) should use
unstable. I mean it.

  You can easily use testing by default, and unstable if the program
isn't in testing, using an /etc/apt/preferences that contains:

    Package: *
    Pin: release a=testing
    Pin-Priority: 990

    Package: *
    Pin: release a=unstable
    Pin-Priority: 500

  Then it'll take packages from unstable if it's not in testing. You'll
have occasionally uninstalability problems when transitions are in
progress though.  My answer wasn't arrogant, I'm merely annoyed at this
discussion where people want testing to be what it's not. There are
technical ways (the one I just cited is one, you can do it other ways if
you like) to cherry-pick some packages from unstable while using testing
for the rest.  You absolutely want to use update-* from unstable ? fine.
Use that, you will continue to use them transparently.

  But I repeat: testing is what will become the next stable. We don't
take buggy software in stable, and for <put your definition of non
essential software here> packages we *do* prefer no packages than a non
working one. If as a user you don't like this policy, then you don't
want to use stable or testing solely.

  I'm sorry if in the discussion I assumed this technical solution was
obvious to the participants of the thread, it was a shortcut, not
arrogance.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Mike Bird <mgb-debian@yosemite.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #150 received at 484129@bugs.debian.org (full text, mbox):

From: Mike Bird <mgb-debian@yosemite.net>
To: debian-devel@lists.debian.org
Cc: 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Wed, 4 Jun 2008 10:30:52 -0700
On Wed June 4 2008 09:36:07 Pierre Habouzit wrote:
>     Package: *
>     Pin: release a=testing
>     Pin-Priority: 990
>
>     Package: *
>     Pin: release a=unstable
>     Pin-Priority: 500

Downsides include:

(1) Not something a newbie should be worrying about.
(2) Bug reports from Testing+Unstable are less valuable.

An alternative approach would be for packages to be retained
in Testing for the benefit of the hundreds of thousands of
desktop and laptop users who need to use Testing, and for
the few members of the release team to use a filtered package
list.  The filtered package list would become the next Stable.

This keeps Testing as it has historically been - more stable
than Unstable and the best Debian for recent hardware.

--Mike Bird




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #155 received at 484129@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: debian-devel@lists.debian.org, 484009@bugs.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Thu, 05 Jun 2008 10:27:41 +0200
[Message part 1 (text/plain, inline)]
Le mercredi 04 juin 2008 à 10:30 -0700, Mike Bird a écrit :
> On Wed June 4 2008 09:36:07 Pierre Habouzit wrote:
> >     Package: *
> >     Pin: release a=testing
> >     Pin-Priority: 990
> >
> >     Package: *
> >     Pin: release a=unstable
> >     Pin-Priority: 500
> 
> Downsides include:
> 
> (1) Not something a newbie should be worrying about.

Fine, that’s not something a newbie should be doing.

> (2) Bug reports from Testing+Unstable are less valuable.

Wrong. They are much more valuable than bugs in testing only, since they
help us see whether some Conflicts/Replaces have been missed.
Furthermore, a user with such a setup can easily upgrade a package to
unstable before reporting a bug that’s already fixed.

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #160 received at 484129@bugs.debian.org (full text, mbox):

From: Johannes Wiedersich <johannes@physik.blm.tu-muenchen.de>
To: 484009@bugs.debian.org, debian-devel@lists.debian.org, 484129@bugs.debian.org
Subject: Re: Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Thu, 05 Jun 2008 15:56:55 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-06-04 18:36, Pierre Habouzit wrote:
>   No it's not. A user that prefers to have broken software rather than
> no software (if the option "non broken" software is absent) should use
> unstable. I mean it.
> 
>   You can easily use testing by default, and unstable if the program
> isn't in testing, using an /etc/apt/preferences that contains:

Thanks for your helping suggestions. For me personally, I don't think it
is a good alternative, since I prefer to stay with lenny after it
becomes stable. Unstable packages leave the slightly bitter taste that a
downgrade won't be supported, once the package reenters testing.

Therefore, IMHO, I prefer to have a package not removed from testing, if
the chances are that it might reenter in the not too distant future, ie.
before the release of lenny as stable.

I agree that it is a difficult decision for the release team to decide
on the fate of a package (not to talk about the fact that there are
thousands of them). Just in my very humble opinion as a user who
doesn't contribute directly as a DD, the decision to remove a package
from testing should not be taken too lightly.

>   But I repeat: testing is what will become the next stable. We don't
> take buggy software in stable, and for <put your definition of non
> essential software here> packages we *do* prefer no packages than a non
> working one. 

Agreed!

My point was solely on the *temporal* removal of packages, that have a
state not as bad as unusable and that have chances of being RC free for
lenny.

As another example take ntp. I don't know the reasons, why it was
removed. If it was removed, because the release team think that the RC
bug can't be resolved in time for release, it's fine with me.

Looking at #448408 it is stated by one of the uploaders, that they just
like to wait for the next stable upstream release. I cannot judge how
likely this is to happen in time for lenny. If the chances are not low,
however, I think it might have been better to leave ntp in testing --
especially since it appears to me that #448408 is just as relevant for
etch and so it doesn't put people upgrading from etch in a worse position.

I stress again that this is just my personal humble opinion as a non-DD
user of debian and please don't take it as an offence!

I very much appreciate the generally *excellent* work of the DDs and the
release team! Thanks a lot for producing such a wonderful distribution!

Thanks to all!!! (I can't stress THIS too much!)

Cheers,
Johannes

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

iD8DBQFIR/CnC1NzPRl9qEURAuuGAJ9TnAnCCjE8EIhUkn2ZdjlmEn9l6QCeLOm9
z5o8a+A/gtutZfREAMvkehM=
=flON
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Adeodato Simó <dato@net.com.org.es>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #165 received at 484129@bugs.debian.org (full text, mbox):

From: Adeodato Simó <dato@net.com.org.es>
To: Andreas Barth <aba@not.so.argh.org>, 484129@bugs.debian.org, Joey Hess <joeyh@debian.org>
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Thu, 5 Jun 2008 22:41:16 +0200
* Andreas Barth [Wed, 04 Jun 2008 07:19:07 +0200]:

> Is there a reasonable way to
> generate pseudo-packages "taskel-$task" that depend on all the packages
> that need to be present to not break anything?

I think britney's FauxPackages would just be very appropriate for this?
(For those reading along, this means the meta-packages would only exist
in britney's imagination.)

* Joey Hess [Wed, 04 Jun 2008 10:58:21 -0400]:

> Andreas Barth wrote:
> > What we should make sure then is that britney recognizes these cases,
> > and shows "breaking task foo" for that. Is there a reasonable way to
> > generate pseudo-packages "taskel-$task" that depend on all the packages
> > that need to be present to not break anything?

> You could use the information about key packages listed in
> /usr/share/tasksel/debian-tasks.desc

Ok, if that's what's desired, I can look into morphing Key packages in
that list into something that'll prevent britney from removing them.

> However, there is no equivilant source of information for packages
> apt-installed by d-i.

Could there be one? Well, if you're interested in having the same
safeguard mechanism in place for these packages.

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
                -- George Bernard Shaw





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #170 received at 484129@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Adeodato Simó <dato@net.com.org.es>
Cc: Andreas Barth <aba@not.so.argh.org>, 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Thu, 5 Jun 2008 16:56:32 -0400
[Message part 1 (text/plain, inline)]
Adeodato Simó wrote:
> Could there be one? Well, if you're interested in having the same
> safeguard mechanism in place for these packages.

It would be nice to have one, but many different parts of d-i decide
what to apt-install, so extracting a list is hard.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #175 received at 484129@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: Adeodato Simó <dato@net.com.org.es>
Cc: 484129@bugs.debian.org, Joey Hess <joeyh@debian.org>
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Fri, 6 Jun 2008 07:30:06 +0200
* Adeodato Simó (dato@net.com.org.es) [080605 22:41]:
> * Andreas Barth [Wed, 04 Jun 2008 07:19:07 +0200]:
> 
> > Is there a reasonable way to
> > generate pseudo-packages "taskel-$task" that depend on all the packages
> > that need to be present to not break anything?
> 
> I think britney's FauxPackages would just be very appropriate for this?
> (For those reading along, this means the meta-packages would only exist
> in britney's imagination.)

The mechanismn: yes. But not FauxPackages itself, as I think we could
generate that list automatic. (For a short-term solution, FauxPackages
might just be ok.)




Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Adeodato Simó <dato@net.com.org.es>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #180 received at 484129@bugs.debian.org (full text, mbox):

From: Adeodato Simó <dato@net.com.org.es>
To: Andreas Barth <aba@not.so.argh.org>
Cc: 484129@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Fri, 6 Jun 2008 08:42:38 +0200
* Andreas Barth [Fri, 06 Jun 2008 07:30:06 +0200]:

> The mechanismn: yes. But not FauxPackages itself, as I think we could
> generate that list automatic. (For a short-term solution, FauxPackages
> might just be ok.)

I meant, yes, adding to FauxPackages an automatically-generated list,
not a list generated by hand. (Maybe FauxPackages should be a directory,
to avoid mixing hand-written stuff with automatic stuff.)

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it.
                -- Brian W. Kernighan





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #185 received at 484129@bugs.debian.org (full text, mbox):

From: Jérémy Bobbio <lunar@debian.org>
To: debian-release@lists.debian.org, 484129@bugs.debian.org
Cc: debian-boot@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Fri, 6 Jun 2008 13:00:50 +0200
[Message part 1 (text/plain, inline)]
On Thu, Jun 05, 2008 at 10:41:16PM +0200, Adeodato Simó wrote:
> > However, there is no equivilant source of information for packages
> > apt-installed by d-i.
> 
> Could there be one? Well, if you're interested in having the same
> safeguard mechanism in place for these packages.

I have made a first one by grepping through the source code.  As
"apt-install" is used in code, we can't really think of automating the
process of creating such list.

The debian-installer team might probably be able to maintain a list in
its source repository.  Would that be fine for the release-team?

In the meantime, here's a first one:

--- 8< ---
aboot
acpi
acpi-support-base
acpid
apex-nslu2
arcboot
busybox
colo
console-common
console-cyrillic
console-data
console-setup
console-terminus
console-tools
cryptsetup
delo
dmraid
dmsetup
dosfstools
e2fsprogs
eject
elilo
flash-kernel
glantank-utils
grub
grub-efi
grub-of
grub-pc
hfsutils
initramfs-tools
installation-report
jfsutils
laptop-detect
libc6-i686
libc6-sparcv9
libc6-sparcv9b
libfribidi0
lilo
locales
loop-aes-utils
lvm2
mdadm
mkvmlinuz
multipath-tools-boot
nis
nslu2-utils
openssh-server
palo
pbbuttonsd
pcmciautils
powerpc-utils
quik
reiserfsprogs
sibyl
silo
sudo
sysconfig-hardware
uboot-mkimage
udev
usbutils
vmelilo
wireless-tools
xfsprogs
yaboot
yaird
--- >8 ---

This list misses the various kernel related packages which versions are
computed dynamically from what is available in the installer accessible
repositories.

Cheers,
-- 
Jérémy Bobbio                        .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to "Loye Young" <loye.young@iycc.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #190 received at 484129@bugs.debian.org (full text, mbox):

From: "Loye Young" <loye.young@iycc.net>
To: 484129@bugs.debian.org
Subject: Better way to handle tasks.
Date: Tue, 10 Jun 2008 02:53:04 -0500
>> > However, there is no equivilant source of information for packages
>> > apt-installed by d-i.

>> Could there be one? Well, if you're interested in having the same
>> safeguard mechanism in place for these packages.

>I have made a first one by grepping through the source code.  As
>"apt-install" is used in code, we can't really think of automating the
>process of creating such list.

>The debian-installer team might probably be able to maintain a list in
>its source repository.  Would that be fine for the release-team?

Our company puts the [distro]-tasks.desc file in the repository in the
same directory as Packages.gz. We make aptitude download the .desc to
the right place on every update. Consequently, all we have to do to
maintain the tasks is edit a text file in the repository, which
automatically gets deployed with every update.

It works for us, and I think it would go a long way to bringing
visibility and ease of management to tasks.




-- 
Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. Full text and rfc822 format available.

Message #195 received at 484129@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: debian-release@lists.debian.org
Cc: 484129@bugs.debian.org
Subject: Re: d-i uses bootloaders
Date: Mon, 16 Jun 2008 14:38:11 -0400
[Message part 1 (text/plain, inline)]
Frans Pop wrote:
> Jérémy posted a full list that included all these in the thread about 
> #484129 and d-release was CCed in that mail: 
> <20080606110050.GA15496@qamar>

And luk added the removal hint for lilo on 20080614 or 20080610 -- after
Jérémy sent that list.

BTW, I've double-checked (ie, generated my own since I didn't know about
his) the list. I'd add linux-2.6 and linux-modules-extra-2.6 to it,
otherwise we made identical lists..

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#484129; Package release.debian.org. (Sat, 21 Feb 2009 19:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luk Claes <luk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 21 Feb 2009 19:48:05 GMT) Full text and rfc822 format available.

Message #200 received at 484129@bugs.debian.org (full text, mbox):

From: Luk Claes <luk@debian.org>
To: debian-release@lists.debian.org, 484129@bugs.debian.org, debian-boot@lists.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Sat, 21 Feb 2009 20:44:13 +0100
Hi

Jérémy Bobbio wrote:
> On Thu, Jun 05, 2008 at 10:41:16PM +0200, Adeodato Simó wrote:
>>> However, there is no equivilant source of information for packages
>>> apt-installed by d-i.
>> Could there be one? Well, if you're interested in having the same
>> safeguard mechanism in place for these packages.
> 
> I have made a first one by grepping through the source code.  As
> "apt-install" is used in code, we can't really think of automating the
> process of creating such list.
> 
> The debian-installer team might probably be able to maintain a list in
> its source repository.  Would that be fine for the release-team?

A list available on some webpage or easily fetchable via a script would
be great.

Is the below list still up to date?

> In the meantime, here's a first one:
> 
> --- 8< ---
> aboot
> acpi
> acpi-support-base
> acpid
> apex-nslu2
> arcboot
> busybox
> colo
> console-common
> console-cyrillic
> console-data
> console-setup
> console-terminus
> console-tools
> cryptsetup
> delo
> dmraid
> dmsetup
> dosfstools
> e2fsprogs
> eject
> elilo
> flash-kernel
> glantank-utils
> grub
> grub-efi
> grub-of
> grub-pc
> hfsutils
> initramfs-tools
> installation-report
> jfsutils
> laptop-detect
> libc6-i686
> libc6-sparcv9
> libc6-sparcv9b
> libfribidi0
> lilo
> locales
> loop-aes-utils
> lvm2
> mdadm
> mkvmlinuz
> multipath-tools-boot
> nis
> nslu2-utils
> openssh-server
> palo
> pbbuttonsd
> pcmciautils
> powerpc-utils
> quik
> reiserfsprogs
> sibyl
> silo
> sudo
> sysconfig-hardware
> uboot-mkimage
> udev
> usbutils
> vmelilo
> wireless-tools
> xfsprogs
> yaboot
> yaird
> --- >8 ---
> 
> This list misses the various kernel related packages which versions are
> computed dynamically from what is available in the installer accessible
> repositories.

I guess that could be included in such a list?

Cheers

Luk




Reply sent to Julien Cristau <jcristau@debian.org>:
You have taken responsibility. (Fri, 13 May 2011 23:24:03 GMT) Full text and rfc822 format available.

Notification sent to Raphael Hertzog <hertzog@debian.org>:
Bug acknowledged by developer. (Fri, 13 May 2011 23:24:03 GMT) Full text and rfc822 format available.

Message #205 received at 484129-done@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 484129-done@bugs.debian.org
Subject: Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
Date: Sat, 14 May 2011 01:21:49 +0200
britney has faux packages in place that are sort of kept up to date with
tasksel's data, and should prevent tasks becoming uninstallable.  So
closing.

Cheers,
Julien




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 11 Jun 2011 07:36:11 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 05:35:49 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.