Re: Please notify the maintainers when removing packages
On Wed, May 14, 2003 at 09:55:36AM +0200, Gerfried Fuchs wrote:
> * 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.
Sure, but the solution is often simple.
> > 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.
Well, it was prior to one of our freezes/releases, my package was about
to be dropped/removed/whatever, if i had not taken immediate action.
It was a few years ago though, and things may have changed some since
then, but it remains that it is easier to overlook a mail from one of
the mailing lists, even if it is a required read and a simple grep or
whatever is needed, than a mail sent to you personnally.
> > 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.
Sure, but it cost nothing, or almost so, so why not send a personal mail
to concerned developers ?
> 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.
Maybe there could be two sections in the mail, one about changes from
the previous week, and the other the global listing as we do now. Sure
it repeats some of the data, but is it that problematic ? Maybe the
second section could be only for older, not changed problematic
packages, or maybe this could be two separate mails.
> > 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.
Hah, and one small mail is going to make a difference compared to the
huge amount of spam that we get trough the debian lists and mailing
addresses ? And anyway, i don't hear the people who would receive such
mails objecting, and if they are not doing their work correctly, they
deserve a reminder. I think people are just rejecting this idea on
principle or something such.
> > 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.
If we had a .procmail rule that would search for ones maintainer address
in the these mails, extract the relevant info and sen it as a separate
mail, then it would make things much easier, without needing to try to
change something on the sending end.
> > 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.
But there is no guarantee of that. I have heard reports lately of
packages that were silently removed, and remember a maintainer wondering
why a package was dropped silently from potato during the release.
Friendly,
Sven Luther
Reply to: