[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx <at> buildd.debian.org sent to /dev/null ?)

On Fri, Dec 17, 2004 at 11:31:55PM -0500, Joey Hess wrote:
> Let's just ignore the several elements of Ingo's mail that seem to
> invite a flamewar, including the multiple ad-homimem attacks. Hmm, let's
> ignore the crying over spilled milk bits too. I'm left with this:

Why do you ignore the truth?
It *is* actually a problem with that person in the project. Why not name it
get a solution?
Instead of discussing the OP problem, the discussion has drifted away to
automated installing procedures now. 
Yesterday I got a private mail from a NM, saying that he won't speak up in
public against some certain persons (which you try to cover the name of, but
here it is: James Troup), because he fears negative effects on his NM
process. And that's not a single person having this fear. Last year I got
the first "I won't say that in public, because I fear the evil DAM"
reactions in my inbox. In private queries on IRC I got other remarks going
into the same directions. 

What kind of distribution is this when people are under pressure not to
speak free about their opinions, because they fear the DAM?

And the DAM is in union of persons to the ftp-master and to some buildd
It *IS* a goddam problem that many people has with a single person, namely
James Troup. 
He has too much control over Debian. One can say he owns Debian in some
regards. He has control over who becomes a DD, therefore he controls
indirectly who can elect in DPL elections, GRs and such. 

So, when you ignore those (as you call it) ad-hominem attacks, I think
you're violating the Social Contract: We won't hide problems!
(Although the following sentence there only speaks of the BTS, I interpret
the title as a general rule for Debian not to hide problems anywhere)

Anyway, back to the original problem of this thread:
Maintainers don't get the feedback from some buildd-admins they need for
doing their work properly. 
When they write to $arch@buildd.debian.org to get a problem solved, they
don't get any replies if their request was even notified and read, not
saying of a notification that the request has been acknowledged and will be
handled properly. This results in a maintainer wasting his time on examining
the situation, looking constantly at various resources on the web and
wondering if his problem gets solved by the buildd admin. When the
problematic package is a package on which many other packages depend on,
this wasted time sum up for several other maintainers, too. 

Remember the qt-x11-free fiasco from January/February this year on mipsel.
Over 70 packages were held back because the buildd admin was
inactive/ignorant/whatever to requests, although the problem was already
known (qt-x11-free being listed in weak-no-auto-build).

And this kind of problems happen over and over again. Search in the list
archives for buildd related problems and requests. You'll find the following
- on some archs there are just requests and replies by non-buildd admin
- on some other archs there are requests and replies by buildd admins and
therefore happy and thankful maintainers, because they know that their
problem is being dealt with...  

Now do a research on who are the persons behind those archs that are leaving
the maintainers standing in the rain, i.e. without any feedback on what's
going on. 

The $arch@buildd.debian.org is just an alias for the buildd admin mail
address, giving the maintainers/DDs an easy to remember scheme to direct
their requests to the right people. 
But those aliases are near to be useless when there's still the
communication problem of some buildd admins.

This kind of problem is known for a very long time now and there's no
solution in sight. Therefore this problem will occur over and over again on
various lists, be it either addressed to buildd-admins or ftpmasters or
ignorant DAM. And it's all about a very single person: James Troup. 

Ciao...              // 
      Ingo         \X/

Reply to: