* Sven Luther <sven.luther@wanadoo.fr> [2003-05-07 12:18]: > On Wed, May 07, 2003 at 09:44:54AM +0200, Gerfried Fuchs wrote: >> 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. > > Yes, sure. But then again, we only have so much free time, and we > prioritize it differently. It happened for me back then, with the > active-dvi package. At the time there was a FTBFS bug or something such > not really all that problematic, and i knew there was going to be a new > upstream release nextly. Well, usually FTBFS bugs _are_ problematic, if people aren't ignorant about other architectures than their own. > If i had not noticed it, the package would have been removed without > any kind of information to the maintainer, and i would maybe not even > have noticed. What makes you think so? I can't follow the reasoning for why you think that it would have been removed right then. > We maintainer are recommended to have good comunications channels to our > upstream, but i suppose that the release manager should have good > comunication channels to the different maintainers to, which doesn't > seem to be always the case. O.k., I can understand that request and it makes sense. I was just under the impression that the "Release Update" mails that the RM sent are much more informative and important to read than the weekly RC bug list. > Also, i understand that they are also MIA maintainers, or semi-MIA ones, > and that for them it will not make much of a difference, but if we help > out even one good-intentioned maintainer, it is already a good thing. The MIA maintainers are a big problem on their own, unfortunately. We definitely should get rid of them or at least be able to get some informations from them to see when they will have time again and suspend them somehow. But that was discussed already quite intensively... >> 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. > > But the bug scan package is not in any readable form. It mostly says the > same as last week. If some kind of diff where available, it would make > more sense to read it. And again I was not talking about the bug scan mails, I was speaking about the "Release Update" mails. I still have the impression that a REMOVE tag in the bug scan mail doesn't mean much but just an indicator on how long a RC bug might be open already. I am still not convinced that packages actually were removed with *only* the REMOVE notification in the bug scan mail. Noone has showed me yet that this impression is wrong. About the idea of "some kind of diff" you got me interested. I might want to take a look on what can be done on that point. Maybe something like (EXAMPLE, there are no such bugreports): Package: t-prot (debian/main) Maintainer: Gerfried Fuchs <alfie@debian.org> New: [REMOVE], 0815 [ + ] Changed: 4711 [P ] (+P) If there are no new RC-bugs or no changes the package shouldn't be listed, if I get you right. I'll take a look on the original script, if I can find it. > It is easy to say that everyone should fix bugs, respond quickly to > mails, and so one, but the people saying it should be held to the same > standard. I try as good as I can ;) > Then mail the debian maintainer that you are going to remove their > package, is that asked too much ? Some developers seem to consider every additional mail by default as spam and object to anything in that respect. But don't get me wrong, I understand your point here. > And beside, it is basic courtesy, but then i have long known that some > of the most important debian people have a tendency to be quite rude > to other developpers. Did i tell you how i got blacklisted by James > Troup when i was too eager to find the reasons for build problems he > told me about in not so clear ways. It seems to be a special sort of "manners" when your higher up, sometimes. Have been in some infight with one of the uppers, too. It's just that because one is longer in the project it doesn't mean that s/he can't be wrong... (and that is no judgement of your problem with elmo; I don't know anything about it) > Well, but if you don't get properly informed in the first place, you may > not notice, and not everyone can pass hours each day to read all the > debian information. Scanning for ones name in the weekly bugscan mail isn't that time intensive, so don't overdo it. > This is wrong, sure the package can get removed if there are RC bugs, > but when will that be, what release schedule do we have so i can > schedule my free time so as to fix that most efficiently ? So simply don't take the REMOVE in the bugscan mail too serious. From what I have understood it was never the last word before a package was actually removed. > It is a simple thing indeed, you have to balance the cost against the > benefit, and if we can reach at least one developer who has maybe by > mistake did miss the removal announcement in dda or something such, then > it is worth it, especially as the cost is almost nothing, a few lines in > a script and that's it. > > And even if the maintainer doesn't care or whatever, it is still the > least of things to be polite and inform people, which is a thing that is > often sorely needed in the debian project. > > And beside, the mail could include a note of the kind 'if you have not > enough time to maintain the package properly, you should consider > orphaning it, or asking for its removal or whatever', which would also > further the quality of the debian releases, but by being insulting and > despreciative, we gain nothing, and just get more recentment and such. > > Friendly, > > Sven Luther -- * TEST -- Ryuichi Arafune, changelog.Debian for imagemagick (4:5.4.6-4)
Attachment:
pgpuMtrGDeMfK.pgp
Description: PGP signature