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
Attachment:
pgpSkHAGuadKH.pgp
Description: PGP signature