Re: serious problems with Mr. Troup
I would like to respond to this message, but to do so honestly and
effectively I'd need to say things which might enrage, no matter how
So I'm going to refrain.
On Sun, 22 Feb 2004 13:17:17 +0100
Ingo Juergensmann <firstname.lastname@example.org> wrote:
> On Sat, Feb 21, 2004 at 08:28:14PM -0500, David B Harris wrote:
> > As I explained to Ingo when he said he required notification prior to
> > any policy change, it is simply *not* reasonable to expect such
> > unconditionally. As a paid systems administrator, I'll make an effort to
> > ensure a smooth transition to any new policy, but sometimes it must be
> > done at the drop of a hat without any warning - and users are left to
> > catch up. It happens, it's unavoidable, and it's part of a good system
> > administrator's job.
> > (That was the only requirement Ingo stated, and he dropped the point
> > after I said what I said above.)
> I dropped it because I see no sense in always argueing with "Debian is not a
> business, only voluntary work and therefore can't be forced".
> When a new policy needs to bet put up immediatedly without prior
> announcement, then this needs to be done. But where was the public
> announcement of that changed policy afterwards? And I don't saw any "Yes, I
> agree to that new policy" mails from other buildd admins as well. So, I
> can't follow the argument that all others have agreed to the policy -
> especially when they even don't know that a new policy exists.
> Raise your hands, buildd admins, who knew of the changed policy before the
> last days?
> > Furthermore, what does it matter if Ingo gets told about a policy change
> > after it's been put in place? I mean, sure, it'd be nice to be kept in
> > the loop, but it's hardly required. Maybe in theory we should all be
> Usually, when someone has a contract with you, he can't change the rules of
> that contract afterwards without your given permission for it. If he does,
> the contract is either invalid or the old contract still is valid.
> > tracking each package we Depend: on very carefully, but in practice I
> > bet that most people (like myself) just care when something breaks. And
> > then we fix the breakage, and it's no big deal, and we move on.
> Yes, the buildd was broken (non-functional), I tried to contact the
> "Maintainer", waited a long term, nothing happened, I fixed it.
> > > Some buildds have gotten access in days (was 2 the minimum?) while
> > > Ingo (and me too) has been left hanging without.
> > I don't see how that's relevant to the discussion. Unless you want the
> > discussion to be about your and Ingo's suitability for the role? I'm not
> > interested in that, so if you are and you say as much I'll just ignore
> > that portion of any followup.
> It's part of the very selective cognition of Mr. Troup and the resulting
> problems thereof.
> If Mr. Troup would have done his work, then the buildd would have added in a
> timely manner. Obviously it is possible for Mr. Troup to add new buildds
> within a day. Why does it last for other buildds some weeks to get added?
> Apparently it is a matter of who is requesting the addition of new buildds.
> That's part of "serious problems with Mr. Troup".
> > For the other two, basically a) remove the mail fitler, and b) promise
> > to respond to things in a timely manner. Well, a) isn't a filter, it's a
> > scoring mechanism, and it's silly to ask for its removal unless you know
> > what it does. Do you have a copy of those recipes/scripts? If so, feel
> > free to provide them as a basis for discussion.
> Acting as "the guy who adds buildds to the ACLs" is a role position. Role
> positions shouldn't have applied filters to communication based on personal
> Surely, Mr. Troup can filter whatever private communication he likes, but
> when he's asked as a role keeper, that isn't appropriate anymore.