Re: buildd administration
Anthony Towns <email@example.com> writes:
> On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns <firstname.lastname@example.org> writes:
>> >> Upstream is working on #335981 and #336371. In fact, scm has *never*
>> >> supported s390;
>> > scm | 5d9-4.1 | unstable | s390
>> And yet, it didn't actually run successfully on s390. Support is not
>> just a matter of compiling.
> Support's a matter of many things. One of those is ensuring you don't
> have RC bugs.
What I said was that scm has never supported s390, but it is intended
to. In my current judgment, it is not ready for testing until it does
support s390. That judgment may change. I was using the word
"support" to refer to a package supporting an arch.
Now you are referring to a very different usage of "support"; that is,
a developer supporting a package. For a package which is not part of
debian stable or testing, it seems to me that support amounts to
actually working on getting it ready for testing and ultimately
> If a package is failing to build or to function on some architecture,
> your job as that package's maintainer is see if it can be fixed (talking
> to porters and/or upstream if it's beyond your skills), and if it can't
> be fixed trivially, to note that it's not currently supported on that
> architecture by both ensuring that non-working packages fail to build
> (by editing the Architecture: line or adding appropriate test suites), and
> passing that information on to others.
This is in fact exactly what is happening.
> In this case that means not having
> a control file that explicitly declares s390 is a supported architecture,
> and filing a bug against ftp.debian.org indicating that the s390 build
> is broken and should be removed. That then warrants downgrading the s390
> FTBFS bugs to important or wishlist.
Yes, because actually *making it work* on the architecture is
unimportant. Well, as the maintainer, I disagree.
> As far as transparency goes; I'll note you didn't add anything to either
> bug report indicating you're working with upstream. It's the silence
> and the uncertainty over whether anything's actually being done to fix
> anything that's the real issue, you know?
I'm sorry, were there people who were worried about this? Were you
wishing that scm worked on your s390 box? I am happy to answer
queries, but I have received none.
In addition, I would point out that your method of "supporting" the
package amounts to documenting its inadequacy and then doing nothing.
My method (described below) is much more focused on actually
furthering development and the usefulness of the package.
> RC bugs need to be fixed as a matter of *urgency*, not over a matter of
The package in question is not in testing, and was not released in
sarge. The RC bug does not affect any users at all. It holds the
package out of testing, which I think is currently appropriate.
Is there some *problem* here? Or are you concerned about a
bookkeeping issue? What is the particular urgency with which you are
concerned? How would it help things if I did as you suggest, and then
opened a new RC bug indicating my judgment that the package is not yet
ready for stable?
What seems patently clear is that you chose to make this the place
upon which to take your stand and criticize me, without having done
the basic research to find out these facts.
Still, you having chosen to do this, my responsiblity as a developer
certainly includes that I should answer your emails as fully and
completely as I can. Are you willing to commit to do the same, and
expect the same of the developers you are so busy defending?
> I don't believe I have any open RC bugs, or any open FTBFS bugs, so
> I don't see the relevance. But hey, if it'll make you feel better to
> convince yourself that it's everyone else's fault and there's nothing
> you can do, go ahead.
Where did I blame anyone? I am addressing the bug in question.
(Actually, you have six open RC bugs, because you "maintain" packages
by ignoring them and relying on others to fix your bugs for you, and
then not acknowleding the NMUs. I fail to see how this is better.)
Nor did I say there is nothing I can do. Instead, what I did was:
1) Adopt the package, since I saw it was having trouble and the
previous maintainer did not seem able to give it the attention it
2) Work with upstream to figure out what archs really worked and what
3) Start addressing the missing archs by helping to get upstream in
contact with experts on those archs, and making sure he had access
to suitable hardware.
4) Lend some expertise as time was available to help with the actual
5) Arrange to have the BTS correctly document the state of the
6) Answer even unfriendly questions from a fellow developer who
doesn't even care about the particular issue.
>> Moreover, please notice how despite a hostile and uncomprehending
> It's amazing how it's always "hostile and uncomprehending" when it's
> you that's being questioned, yet when you're doing the questioning they
> tend consistently towards "concerned and incisive".
I am certainly entirely uncomprehending about buildd maintenance. I
am not hostile about this issue, but I have been about some in the
past. But you miss the point (not surprisingly), which is that what I
*do* in response to the question is not ignore it, and not pretend
that it doesn't count, but patiently continue to answer it. I will
continue to do so as long as you think it is worth discussing on
> Given your apparent discomfort with that question, perhaps you'd care
> to consider how much more "hostile and uncomprehending" it might seem
> if instead of making the question as part of a conversation between us,
> I'd instead posted to d-d-a about it, or simply raised it as a general
> conversation piece about how people in your position should be reviewed
> for replacement as a matter of urgency.
If someone believes that they would do a better job maintaining scm,
I'm entirely happy to hand over maintenance of it. Are you