Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
* 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
-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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
* 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 Description: Digital signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
* Adeodato Simó ([EMAIL PROTECTED]) [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
-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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
-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- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 Description: Digital signature
Bug#484009: Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Wed, Jun 04, 2008 at 02:11:51PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1rhWzGZOef.pgp Description: PGP signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Mon, Jun 02, 2008 at 11:16:51PM +, 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=bothsortby=srcpackagesignhinted=onignclaimed=onignnew=onignmerged=onignnonfree=onignbritney=onignotherfixed=onnew=20refresh=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·
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Mon, Jun 02, 2008 at 04:27:08PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgpR8jeFzYQL6.pgp Description: PGP signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 Description: Digital signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Tue, Jun 03, 2008 at 04:42:22PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKxpOzHLDLN.pgp Description: PGP signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On Tue, Jun 03, 2008 at 08:08:07PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOEE1oAvoNh.pgp Description: PGP signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 Description: Digital signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
* Joey Hess ([EMAIL PROTECTED]) [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
