On Tue, Oct 31, 2006, Noèl Köthe wrote:
> Thats very sad.:(
(I have no idea why you find it sad. I don't find it sad.)
> Why not closing them when uploading?
I told you how we track new upstream releases. We do not need "new
upstream release" bugs, these are only reminders, and are only needed
when the maintainer did not notice a new upstream release.
In other words, these are:
- useless
- waste our time
- are a form of saying we are not keeping up (although I personally
don't care about this part)
Not only does it waste our time *receiving* these bugs, it also costs
us time *closing* these bugs; it is also some kind of pressure we don't
need since we already get multiple and numerous notices when a new
upstream release pops up...
> Thats the idea behind the wishlist new upstream bugs in general.
Yes, but you should not file wishlist bugs blindly. These clutter the
BTS, and the mailbox of the maintainers. Filing a bug for something
which would have been fixed without a bug report is wasting your and
our time as well as technical resources. Your bug reports wont affect
in any way the time at which the upstream release is uploaded to
Debian, in fact these are only slowing things down.
> I check pkg-gnome and debian-gtk-gnome@, what is the plan/idea behind
> the patitial uploads of 2.16 to sid and because there where no info
> (today Josselin wrote an info) I wrote the wishlist reports.
Why do you need to know about our plans? We talk inside the team of
our plans between us, but we don't justify each and every upload we
make. Can't you simply trust us?
> Closing them without fixing them is sad.:(
Some bugs are invalid, and are closed without upload, because they
don't need "fixing".
I want to discourage sending of new upstream release requests on
pkg-gnome. Your bugs had a value of *zero* but did cost us time. It
took you one minute to file them, and it took me one minute to close
them. Would I have had to close them with each upload, I would have
checked the bug number to close on each upload, and I would have spent
too much time and energy tracking them.
What does the bug report add really? Absolutely nothing, you can
track the uploads via the PTS, your bug reports are not making the new
upstream release arrive faster to Debian ... quite the contrary.
Would you imagine filing a bug on linux-2.6 requesting 2.6.19-rc2 to be
uploaded to experimental? No, nor did anyone file requests for any
2.6.18.* release or any major release. Go check:
/usr/share/doc/linux-image-2.6.18-1-686/changelog.Debian.gz
search for "new upstream", and see how many closed bugs it has.
> There is the real reason, you request, to have 2.16 packages. It would
> be enough to have them in experimental but there aren't all in
> experimental.
(I can't parse your above paragraph.)
> Go ahead creating your own rules for closing bugs.:(
Geez, did I accuse you of not following the rules for mass bug filing?
I accepted your first isolated bug report, and silently uploaded a new
upstream release to experimental, didn't I? Then you came with your
denial of service attack over the GNOME team's mailing list, I give you
the *rationale* why we don't want such bug reports (I think I gave you
a pretty good explanation in my first mail already), and you insist
that this bureaucracy is deserved, and I should honor your request?
Please look at my closing message again: "Please stop filing these
bugs" => this is a kind request to please stop, followed by an
explanation, of the why it's not needed, why it costs time, and even
the other methods we have to handle this.
In other words, it is not helping to file these bugs, it wastes our
time. I can't say it anything else, it's the truth. The only action I
can take against it is to explain you why these bugs are not helping,
and closing them.
Instead of filing new bugs, I invite you to join #gnome-debian on
GIMPNet (irc.gimp.org IIRC), and help us prepare and upload new
upstream release. There's a low overhead in getting in the team, and
we're needing help, especially from DDs which already have upload
rights and competence.
--
Loïc Minier <[EMAIL PROTECTED]>
