Re: buildd administration
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns <aj@azure.humbug.org.au> writes:
>> > That's non-sensical. Everything the buildds do is logged pretty much
>> > immediately onto http://buildd.debian.org/, which also provides long
>> > running statistics on how effective the buildds are, and even a schedule
>> > of what the buildds will be working on next.
>> That tells us what the buildds are doing. It doesn't tell us anything
>> about what the buildd admins are doing.
>
> It tells you what the buildd admins are doing with the buildds.
No. It tells us some of what they are doing. It does not tell us
everything; sometimes there are problems which are hard to diagnose
without more specific information.
> It doesn't tell you why they're doing that, of course, but if that's
> what you want to know you're better off creating an environment where
> folks are interested in talking to you.
I see. Can we please post a list of the Debian developers who have
blacklists like this, and exclude them from single-point-of-failure
jobs? Is it ok for me to decide to ignore bug reports from people,
merely on the grounds that I am not interested in talking to someone?
> No, because I've no idea what your request was or what its importance
> was compared to other pressing issues.
It was poisted on debian-release.
> If there was a page tracking such
> issues that I could follow -- like the one Jeroen set up for tracking
> and diagnosing removals needed from the archive prior to his inclusion
> in the ftpteam -- I might be able to do so, but I understand you're
> dismissive of that approach.
No, not in the least. That's a good start, but for it to be an
excellent start, it needs to work like the BTS, and be something that
the relevant volunteers themselves read and pay attention to.
> Not at all. Indeed, that's happened in the past -- Joey and James
> tried to close new-maintainer in July 1999 insisting they needed help,
> and n-m continued in a crap state until October when James quit from
> new-maintainer outright. It nevertheless took until April 2000 before
> new maintainers began being accepted. And new-maintainer's not without
> it's continuing problems even after that process. I don't think that's
> a model that bears repeating, personally. You're welcome to your own
> opinion of course.
I'm not sure I understand. Joey and James tried to *close*, which is
not at all the same thing. Indeed, my recollection was that they
resisted any actual help, they insisted that their role was absolutely
essential, and both refused to process applications and refused to let
anyone else take over the work. Finally James stopped, and things
began to slowly improve.
>> It is clear that some of the fiefdoms are run by people who adopt this
>> attitude: "If you criticize me publicly, then I will slow-pedal your
>> requests."
>
> Perhaps you should talk to Nathaniel, who seems to think public criticism
> is effective in today's Debian, and work out some consensus reality.
No, I don't think it's effective. I think it's counter-productive.
But that does *not* mean that it's not *equally* counter-productive to
maintain blacklists, ignore email, refuse to post status reports or
discuss issues, and the like. Indeed, I think those things are ever
more counter-productive.
Moreover, if those things are done, the public criticism tends to
get massively reduced pretty quickly, because if it's misplaced,
everyone can clearly see.
An excellent example of this is the publication of the NEW queue. Now
that everyone can see the NEW queue, I don't see any of the big public
criticism about slow processing.
>> This is an infantile and counterproductive attempt to
>> maintain control and a sense of superiority.
>
> I don't believe this is the case. If you believe you know the people
> involved better than I do, and your judgement is thus better informed,
> you are, again, welcome to it.
Actually, we don't know who the people are at all. One cannot even
find out the *names* of the people doing this work.
> (BTW, I see #335981 and #336371 haven't received a response since late
> October; or has raptor been down that entire time, so that you haven't been
> able to diagnose it further -- it certainly seems down now?)
Upstream is working on #335981 and #336371. In fact, scm has *never*
supported s390; when I took over maintenance of the package I opened
the bugs so that it could be more effectively tracked.
And since I am the one who opened #335981, I don't really think a
reply to myself is all that necessary. #336371 was opened as a result
of a normal build failure, by someone who performs the useful task of
opening FTBFS bugs when appropriate; a personal reply does not seem
necessary.
Certainly if I received a question about the bugs, I would reply as
soon as practicable.
Thomas
Reply to: