Re: serious problems with Mr. Troup
On 22 Feb 2004 01:07:24 +0100
Goswin von Brederlow <firstname.lastname@example.org> wrote:
> > > It's not about agreeing to that specific policy, but about how that got
> > > communicated and how future cooperation with Mr. Troup should look like. When
> To say it in different words. Ingo can agree to it but not accept it
> without some further understandings. Reasons being the communication
> blackout and general implementation of the policy.
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
(That was the only requirement Ingo stated, and he dropped the point
after I said what I said above.)
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
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.
> 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.
> > I believe James' communication on the matter was more than clear. "Ingo,
> > I said non-negotiable and I meant it." That was obviously a direct reply
> > to yourself.
> How about James
> - creates the missing user/pass pairs for the buildds (point a of
> Ingos concerns)
> - agrees to removes the mail filter (concern b)
> This could be limited to the, to be created, buildd-admin
> mailinglist where changes and news concerning buildd should then
> be announced prior to implementation when possible.
> - agrees to respond to the then unfiltered mails from ij concerning
> buildd/wanna-build operations in a timely manner (concern c)
> - creates a new set of user/pass pairs for every buildd working before
> the compromise (concern d). The existing user/pass keys are
> compromised (they appear(ed) in log on buildd.debian.org) and any
> security measure is useless without changing them.
> And Ingo accepts the new policy.
> Does that sound unreasonable?
Well, two of the points have nothing to do with communcation. If you'd
like to bring them up as seperate issues, please respond to
<email@example.com> wherein I briefly
outlined the issues presented.
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.
As for b), I'll refer to tbm's
<20040220163532.GC1629@deprecation.cyrius.com>. I'd also add "there are
some things more important than m68k buildds". If you'd like to outline
the timeframe for the specific conversation quoted in ij's email, feel
free. Until that information is made available it's impossible to judge
whether the turnaround time has been good or not.
So does what you said sound reasonable? Taken entirely out of context,
yes. Taken with context, no. Not to mention portions of it being