Re: MIPS port backlog, autobuilder machines and some arrogance
On Sat, Nov 22, 2003 at 01:33:14AM +1000, Anthony Towns wrote:
> > And to answer, yes, I believe I can back up what I said on the topic.
> > Perhaps there are some intricate details in the system of how donations
> > are processed, but I rather doubt that it isn't something that a developer
> > like myself could handle, provided one is diligent enough.
> I'm sure there aren't. I'm sure lots of people could handle the work
> involved in keyring-maint, web maintenance, and maintainership of most
> of the packages Debian, too. But that doesn't make it trivial to add
> redundancy in any of these areas; because, again, if it were, it would
> already have been done.
I didn't claim it was trivial.
> There are generic problems here: since we can't offer any real
> compensation for people doing the work, we have to find someone who
> thinks it's more fun or more important than anything else they could be
> doing. We also have to make sure that their work doesn't conflict with
> Mako's work and that we can avoid too many negative repurcussions from
> inconsistencies. We also have to make sure the people involved know when
> they should be acting and when they should leave it for someone else,
> otherwise you can end up with no one doing anything, or with people
> getting irritated at having wasted their time redoing something someone
> else has already done.
All of these things you mention are valid, but being generic, they have
already been solved in several other groups (and likely unsolved in others,
but that's not usually due to their inherent nature). This is what I
referred to as "Not Invented Here attitude" -- I am perfectly aware of the
above because I have been and continue to solve them all the time in other
group tasks. My opinion on group task management in Debian would be that
when in doubt, it _can_ be done, not the other way around.
> The real question is how big the problems are that could be fixed by more
> redundancy, and how much pain the generic problems listed above are *in
> the specific case*. It might be really easy to get more people doing the
> hardware donations thing; but given that it hasn't happened already, that
> doesn't seem terribly likely.
I wouldn't go so far to say it's really easy, but I also wouldn't go so far
to say it's too hard.
> > > Again, I never accused you of not knowing anything about this. I said
> > > that your post didn't demonstrate any knowledge -- "more redundancy is
> > > good" isn't any more helpful than "too many cooks spoil the broth", or
> > > "a bird in the hand is worth two in the bush".
> > >
> > > All those things are true, and can be a useful starting point for
> > > thinking about problems that show up; but they're a starting point only,
> > > and mindlessly repeating them at people who are already well aware of
> > > the cliches isn't helpful.
> > I'm not mindlessly repeating it, nor am I convinced that the people are
> > already well aware of them (most probably aware of the principle, but
> > obviously not in the specific case).
> *blink* So you're claiming that Martin's lying when he says "I'm well
> aware that redundancy has several benefits" ?
That statement is generic, and this specific case has no redundancy yet.
I don't see what I said wrong.
> > my "expounding" on the "cliche" was supposed to be a simple, clear reminder.
> ] Since you're posting that as the DPL you're asking for the following
> ] reply. Sorry :)
> ] It's been proven plenty of times that whenever we have task depend on a
> ] single person doing it, the lack of redundancy comes back and bites us in
> ] the ass whenever there's the slightest bit of a problem.
> That doesn't sound like a reminder to me; it sounds like you're saying
> that the DPL hasn't been doing his job.
It's both. (Aiee! HE ACCUSED TEH DPL! BURN THE WITCH!)
I don't consider it a bad thing to tell people that they did something wrong
and that they need to improve. If we only communicated pleasant smalltalk,
that would be idiotic.
> But unfortunately you apparently *don't* know the details of what
> you're talking about; otherwise presumably you'd have known that Mako
> and "another developer" are "working on a system which will allow them
> to coordinate this task". And that pretty much means you shouldn't be
That statement is just about as generic as it can get and indicates an
intent rather than actual progress (at least I don't remember seeing anyone
other than mako on the alias the other day when master was still available,
for example). I don't think that the fact they are contemplating or testing
stuff forbids me from saying they should have done that already.
> Finding out what's already been done, doing something to move things
> along, going into detail to help people work through problems that they
> don't see solutions to -- all those things are valuable. Repeating things
> that everyone knows to be true isn't.
You seem to consider it unhelpful to even mention that there's a problem
just because you assume everyone knows. To me it seemed like nothing
concrete was done, so the latter assumption wasn't particularly likely. I
would be glad to go into details and help them however I can, but nobody was
even talking about the issue, at least not to my knowledge. Yeah, you could
hurl that back at me (why didn't I ask them rather than poking the DPL?),
but then we're going in circles.
> I feel obliged to add that saying "the things this person has said are
> stupid" is just criticism -- it's fair to be very wary of ad hominem
> arguments, and it's fair to consider insults impolite and unnecessary,
> but being offended by criticism is unhealthy.
>From where I'm sitting, you're responding to my criticism by saying how I'm
talking utter nonsense just because my criticism wasn't pointed to a
specific, exact set of broken up issues and based on a set of detailed
facts. It would be nice if the latter was done, but the lack of it doesn't
imply that the problem is being handled perfectly and that nobody should
even bring up the question. Conversely, I feel it's unhealthy to have an
atmosphere where criticism is dismissed based on assumptions.
2. That which causes joy or happiness.