[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Advice with uncooperative maintainers

On Wed, Aug 11, 2004 at 06:17:07PM +1000, Anthony Towns wrote:
> On Wed, Aug 11, 2004 at 02:50:20AM +0200, Robert Millan wrote:
> > I'm seeking advice on dealing with uncooperative maintainers.  
> It takes two to cooperate. 

True.  I can show you practical examples in which I sent you bug reports and
your unwillingness to cooperate or even respond to the bug report trashed the
work I submitted.  Want me to dig up?

> What appears to be missing in this instance is any possibility
> of help from you in satisfying Ryan's goals; meanwhile calling Ryan
> "uncooperative" on -devel and doing BSD specific NMUs when Debian's trying
> to freeze are both likely to actively work against Ryan's interests. Is it
> really unclear why you don't have an idyllically cooperative relationship
> with him?

1)  You appear to be impliing that Ryan's goals don't include appliing patches
    from bug reports he agrees with, and replying to bug reports he doesn't
    agree with (particularly important when the submitter announced intent
    to NMU).

2)  I don't have any reason to disagree with Ryan's goals since I haven't
    heard of them yet.  What I do have is an objection to his behaviour, which
    is completely different.

3)  The phrase "doing BSD specific NMUs when Debian's trying to freeze" is a
    pitiful attempt at pretending that my NMUs are against the freeze or the
    release process.  Argumenting like this, I could argue that adding new
    features to a package, or packaging a new upstream during the freeze is
    against the goals of the project.

    (In fact, a wishlist item that requests adding a new feature or packaging
    a new upstream version has a lot more potential to break things than a
    porting patch that, in principle, has no effect on release arches.)

> > What am I supposed to do on this?  Bring the issue to the technical committe?
> > Speak with the DPL? (As the tech ctte documentation suggests). I'll appreciate
> > any constructive feedback on this.
> It sounds more like you're looking for an alternative way of getting
> what you want that doesn't require you to cooperate with Ryan. I don't
> actually think that's an entirely unreasonable thing to want, but it
> has different answers to the question you asked.

That's not true.  I never objected to put an NMU on hold for the sake of
benefitting the release process.  When I announced intent to NMU libtiff
last week, I was notified that this could be disruptive for the libtiff4
ABI transition (which I was unaware of).

Steve Langasek told me that if I did the upload with urgency=medium before
Aug 5th, the "danger of causing a delay [was] minimal".  I finaly opted for
putting the NMU on hold _on my own initiative_ without being asked to do so.

I encourage you to read the bug log (#227486), it's pretty illustrating on
how people can be cooperative.  You could learn something from it.

Robert Millan

(Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\
(kernel of *(Berkeley Software Distribution))

Attachment: signature.asc
Description: Digital signature

Reply to: