* Sven Luther <sven.luther@wanadoo.fr> [2003-05-05 15:34]: > On Mon, May 05, 2003 at 02:53:16PM +0200, Michael Banck wrote: >> I suspect that packages don't get removed just for the fun of it, but >> because they have release-critical bugs, which are documented in the >> BTS. I mean, *sheesh*, having release-critical bugs *is* the >> notification that a package will get removed from testing before the >> release, should the maintainer not fix those bugs. > > Yes, but what does it cost to send the email ? Like some other said, > nobody reads the email sent to d-d-a. But they *should* read the bug mail they receive, and I guess that was Michaels point. If they don't read their bug mails they don't seem to care about their package anyway. Still, this doesn't give much meaning to the bug report mail to dda, true. > In one of our last releases, packages got removed, and once we released > without them, and people upgraded, they got upset and complained about > the missing packages. They got responded with disdain that the removal > was announced to d-d-a and that they should have noticed. Those removal notices were *not* the usual release critical bug report mails, those removal notices were _seperarted_ mails sent in by aj. Again, not much meaning for the bug report mail. > Also notice that d-d-a only addresses the debian developers, not the > random users which may be interested in the package and would go bug > fixing if they knew their package would be about to be removed. If the users may be interested in the package they definitely *should* subscribe to d-d-a. d-d-a does *not* only address the debian developers but all the people that are interested in the development of debian in general. That is, also those interested in any single package. If they would go bug fixing they can on the other hand subscribe to the PTS and get notified there about the bugreports. They can also scan the entries at <http://bugs.debian.org/$PACKAGE> to see if there are release critical bugs. > I think the thinking behind this is because these packages are not > properly maintained or something, we should not care much about them, > and their maintainer is in the wrong, since he did let it happen in the > first place, and doesn't read the announcement in d-d-a. Right. Developers that do care about their packages definitely _must_ know about releasse critical bugreports their packages have, and be aware that they might be deleted. > I had one package that almost got removed, and which i noticed at the > last moment. The bug in question was of questionable value, and i let it > open because there were more serious things i was working on in my other > packages. Have you added a hint for the RM in the bugreport so he might know about your thoughts? I am quite sure that aj scans the RC-bugs and looks what the bug is about. Hell, he sometimes lowers bugs that are not worth RC status, and I am confident that he would have noticed a hint about the bug if you would have mailed it to the bugreport. If you didn't, how should the RM know about your thoughts on the bug? Or more general, how should *anyone* know about your thoughts on it? > It was a question of priority of spending my free time, not that i > didn't care. Then note that in the report, is that asked for too much? > And anyway, the removal is an arbitrary decision on the part of the > release manager, not something automatic defined in clear cut rules, so > a bit more public notice is ok in this. The RM *DOES* more public notices than the weekly report mails. Please check the archive of dda from before the woody release. If you have noticed his mails it is not aj's fault. >> > I think the correct solution to this is to fill a bug report stating >> > the about to be removed or something such of the package, so that both >> > the maintainer get informed and also the user who cares about the >> > package. The users who care about the package and also the maintainer *are* noticed with the filing of a RC bug that the package might be removed. It's not that the RM comes the next day and removes the package. There is a lot of water running down the $your_favorite_river before the package actually gets really removed. If you like I might set up a cronjob that scans the RC bugs and mails a "Your package might got removed." after a month after a RC bugreport hasn't been dealt with. > Please tell me, do you really read the full content of the bugscan mail ? No, I don't. But I do read the full content of the removal mails from the RM and I do read the full content of my bugreports (not only the RC ones). Do you? > You haven't given any argument to why _not_ to send a mail to the BTS or > the package maintainer, and given the real minimal cost of doing this, > there is really no sane reason not to send this mail. There *is* a mail in the BTS that gets forwarded to the package maintainer, the RC bug report. > The correct way, as i see it, would be to send a mail to at least the exact > bug entry that is triggering the removal. If there is no such bug > report, removing the package is premature, since it is because of > problems that have not been reported. If there are more than one, fine, > send a mail to all of them. I'm in the impression that no packages were removed without prior notice of the RM to dda (and I'm _not_ speaking of the weekly RC bug summary mails). Do you have any hints that there were packages removed without a seperate mail? If you don't, then IMHO your reasoning is quite moot. > Sure, sure, just provide true argument instead of the 'no there is no > reason for it.' you are giving. Just questioning your reasoning, if its not just a "fed up because one of my packages got almost removed because I didn't care enough". Have fun! Alfie -- <Getty> intelligenz? <Getty> hallo? <Getty> ich hab bandbreite und rechnerpower ich brauch keine intelligenz ;)
Attachment:
pgpaeamFhCkxF.pgp
Description: PGP signature