Re: Please notify the maintainers when removing packages
On Wed, May 07, 2003 at 09:44:54AM +0200, Gerfried Fuchs wrote:
> * Sven Luther <email@example.com> [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.
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. Now activedvi is a nice but rather little used
package, especially back then, and i devoted my debian time to working
on the more important ocaml package, which is more widely used and many
packages depended on it. Given also that there was only neboulus
information on the whole freeze/release schedule, i didn't think it was
such urgency to fix the activedvi issues. I did catch the bugscan report
by pure chance (and it was remarquably smaller back then) and took the
time to fix these issues. 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.
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.
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.
And also, i always respond to personal mail and bug report in a few
days, never more than 3 days or such, which is not something you can say
from everyone, and especially the ftp-masters or the release manager.
> Still, this doesn't give much meaning to the bug report mail to dda,
> > 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.
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.
Also this doesn't take into account the user who does need or is
interrested in a package, and may not notice that it is going to be
removed, especially if he don't track testing/unstable.
I suppose that at least some of the debian developpers started by just
being interested by such a 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.
Sure, sure, but this is all no excuse for not informing the package
maintainer properly. And in general, i feel it is being rude and
despreciative with the package maintainer, which in turn create
resentment and such, and is something we should work to avoid,
especially given the really small cost of what is involved here.
And i would have felt rather pissed off if one of my package was
silently removed from testing. The same as i didn't felt very proud of
being part of debian when after a having worked to bring my packages and
those of some others to be ready for testing, my bug report about
removing two packages from testing got simply ignored for weeks (well 1
or 2 weeks).
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
> > 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.
Yes, but again, this doesn't take prioritize and limited time into
account. We do as we can, and in the same way that the release manager
(or others) is working hard and gives his free time and it is
understandable that he doesn't always respond immediately to emails and
bug reports, i think the same courtesy should be applied to all
developper, even if they can only devote less time to debian, and there
is no reason to make live more difficult for them if it is not needed.
> > 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 long time ago, i don't remember the details exactly, but at
least my users where aware of it, and i am sure some information about
it was posted on the debian-ocaml-maint mailing list.
But it goes both ways, how should i know what the RM thinks about it ?
And sending me a mail about it gives me the chance to respond to the RM
about the situation.
> > 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?
Then mail the debian maintainer that you are going to remove their
package, is that asked too much ? It takes even less time and can be
automated in a few lines or such. 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.
> > 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.
Again, i understand all that, but still, what does it cost to send a
personal mail to the maintainer ? Nothing, then why not do it. I have
the feeling that this is meant as a kind of punition or something such
from the RM to those who don't fix their RC bugs fast enough.
> >> > 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.
No, they are noticed that there is a RC bug, which may, or may not, be
fixed soonly, it does say nothing about the eventual removal of the
package. The correct way of doing this is to send an update to the RC
bug that if nothing is done in x days, the package should be removed.
You were telling me that i should write this kind of stuff to the RC bug
myself, but it is ok for the RM to not do it.
> 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.
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
> 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.
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 ? It would be
ok if it was something like 'a month before the freeze, packages with
open RC bugs will be removed', but since we have no idea when the
release will be, and since the freeze time has disappeared.
> > 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?
Yes, and i even respond within days (or maybe hours) to every bug report
i receive, something the RM does not do. And how many bug report without
any kind of followup are there in the BTS ? You will find no such things
in my packages.
> > 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.
Sure, sure, i responded to this above.
> > 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".
Not because i didn't care enough, but because i did care more about
other more important packages.
And again, there is no argument for it, just statement on the limit of
the insulting and questioning my reasoning ability.
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.