Re: [edd@debian.org: ]
Steinar H. Gunderson writes ("[edd@debian.org: ]"):
> Dirk requested that somebody forwarded this to the list, so here goes. :-)
Thanks.
Dirk Eddelbuettel <edd@debian.org> writes:
> [stuff]
Dirk, I'm not sure I understand the thrust of your argument. The main
thing you seem to be disagreeing about is whether there is a `bug in
rpvm'.
I don't think anyone is arguing about whether there should be a code
change made to rpvm's source package. If you say that the R build
arrangements will automatically generate a properly working rpvm as
soon as the deficiency in pvm is remedied, then I'm sure we're all
happy to believe you. So we can all agree that there is not a bug in
the source code for the rpvm package.
Also, it seems to me that everyone agrees that there is a deficiency
in pvm's source package, in that it fails to arrange for the necessary
libraries to be produced. So we all agree that there is a bug in the
source code for pvm the pvm package; this bug of course translates
into a deficiency in the binary packages too.
The only remaining questions, surely, are who should do the work to
fix the situation, whether the changes should be included in Sarge,
and how to represent this situation in the bug system ?
These are essentially process questions which the TC doesn't have
formal jurisdiction over, but since we have been asked we are trying
to help by coming up with a decision. Do you disagree with the
proposed resolution (aside from the one quibble which I'll mention
below) ?
To respond to some of your detailed comments:
> 10. I made my case, someone else asked for rule by committee. So be it.
> You may decide that it is a bug in rpvm despite my best efforts to prove
> the contrary. In any event, I am rather unlikely to be dedicating much
> time to fixing pvm, so unless something happens there, the status quo of
> this issue is unlikely to change.
That's quite fine by us. Everyone in Debian is a volunteer, and you
are /not/ required to do any work to fix problems affecting your
packages. By the same token, however, the pvm maintainer is not
required to do that work either. All that is required of a maintainer
is that you don't stand in the way of people who _do_ want to do the
work; for example, if someone were to provide sensible patches to the
pvm maintainer then the pvm maintainer should accept them.
For the avoidance of doubt, when we say that you
16. [...] should (if [you] see fit and are able) prepare [a patch]
we explicitly mean, by the use of `if [you] see fit', that you have
free discretion whether to bother or not.
Personally I don't share Bdale's opinion that this _must_ remain an
open bug against pvm. I think you would be quite within your rights
to just close the report against rpvm -- or to change it to wishlist,
reassign it to pvm, and merge it with the other bug. Or you could
leave it open as wishlist against rpvm (as `it would be nice if rpvm
were supported on the other architectures').
But of course Bdale's point about bugs is quite true: the fact that
there is a bug open against your package is no bad reflection on you.
It is merely a way of recording in the project's shared databases the
fact that there is a problem with rpvm - and, you must agree that
there is a problem with rpvm's binary packages even if the cause is
not in rpvm's source.
For this reason I do agree with Bdale that there _ought_ to remain an
open bug against rpvm, but we're not proposing in our resolution to
overrule you. My proposed resolution explicitly reasserts your
jurisdiction over the severity of the bug against rpvm and since we do
not state that we're overruling you (and aren't looking for a 3:1
supermajority) you may choose not to accept our recommendation as it's
a decision regarding your own work, as stated in the Constitution.
If you're going to close the FTBFS bug against rpvm I would suggest
adding an explicit architecture specification to prevent autobuilders
from tripping up, if you haven't already. Of course you may find it
more convenient to maintain a bug open against rpvm which would serve
to inform users of the situation - and let them know what task needs
doing (namely the fix to pvm).
On the other hand, for bugs against pvm, the pvm maintainer is in
charge and you should not fight them in the bug system.
> 6. [...] If something does not build because basic assumptions are
> not met -- despite the fact that Debian Policy /clearly/ requires
> them -- then asking R to code around it is plain wrong. After
> all, we do have the Debian Policy to be able to rely on basic
> assumptions.
I agree that Debian Policy is indeed very useful and generally
sensible, but the TC generally doesn't refer to policy when making its
decisions, except as an informal guide. The TC is the body which
would overrule the policy process if necessary, so the TC is free to
disagree with policy if it chooses.
> 3. Because it is so scripted, I as principal maintainer for R and the
> majority of r-(cran|bioc|omegahat|noncran|other)-* packages, have
> developed a standardized debian/rules file [...]
I'm sure I speak for everyone when I say that we all approve of this
kind of thing and I'm pleased to hear you say that it works well.
> 6. Your suggestion of making 'any changes to rpvm to make use of the new
> library' is wrong. [...]
I explicitly say `any changes'. `Any changes' means `the changes if
there are any (but we don't know or state whether there are)'. It is
good that things are automatic enough that we expect that no changes
are needed. Note also the use of `(perhaps)'.
> 7. Which is why I won't code around the shortcoming [...]
This is fine; I don't think anyone is suggesting that you should.
> Not every package will always be available on all platforms. But
> until the pvm libraries can be built in a Debian Policy-compliant
> way, I don't see how we're going to have rpvm on more than the
> current two or three arches. I don't have time to patch packages
> outside of my 70-plus packages, Quantian, real life, and what
> have you.
As I say, no-one is insisting that you do any work. You are a
volunteer.
> Someone please forward this to debian-ctte where I cannot post for lack of
> a subscription. I have CC'ed just about anybody who has contributed to this
> thread in the past.
Thanks to Steinar for forwarding the message. I apologise for the
difficulty; I'm working on a better approval scheme for the list which
I hope will make life more convenient, but I'm being slow about it
because it has only just made it to the top of my todo list.
I'm afraid that there is another mail problem. I see from the headers
of your mail as forwarded by Steinar that you tried to send it to me,
but I haven't received it. I hope you received a bounce. I'll be
contacting you from my postmaster address (which has a maximally
liberal acceptance policy) to discuss the mail problem.
In the meantime I'd just like to warn everyone that even if it looks
like Dirk sent me a mail I may not have received it.
> PS Ian, great to hear from you. A few years ago, you offered to
> reverse-adopt your own auto-pgp package I RFA'ed over five years ago. Are
> you still interested?
We should sort out our mail problem and discuss this.
Ian.
Reply to: