Re: roaraudio dispute
Steve Langasek writes ("Re: roaraudio dispute"):
> On Sat, Jul 21, 2012 at 07:34:36AM +0930, Ron wrote:
> > Trying to conflate this with the mumble issue however is Not Helpful.
> I agree. I don't see any reason the TC should be revisiting maintainers'
> decisions to drop celt 0.7.1 as a dependency; the mumble case is a very
> particular issue related to the exact manner in which the server is
> repeating the audio to all clients, and I don't see any reason to suspect
> this would be an issue for the other packages that have dropped celt
The reason I was asking these questions about roaraudio is that there
seemed to be a connection between roaraudio and mumble, via celt, and
I wanted to make sure that I understood the whole problem and its
context. I have had private conversations with some aggrieved parties
who were quite concerned about roaraudio.
One of the possibile options for the TC would be to direct that
libcelt be kept in wheezy not just for the benefit of mumble but also
for the benefit of roaraudio. And then the question arose whether
that would be a good idea, which also involves understanding why
roaraudio's rdeps removed or demoted their dependency on roaraudio,
and better understanding the history of roaraudio.
Since I didn't know anything about the history of roaraudio and its
bugs, I asked about the reasoning and communications behind those
Based on the information I have seen so far it seems to me that the
removal of celt support from roaraudio, and the removal of the
dependencies on roaraudio, for the wheezy release, are correct
decisions from a technical point of view.
Having said that I am concerned that there has been impropriety in the
We'd like to have nothing depending on roar for wheezy
Without the background knowledge the most natural reading of that
message is that there is some technical problem with roar which cannot
easily be fixed, and that the roar maintainers agree. The maintainer
of cmus took it as a request from the roaraudio maintainers to remove
the dependency. That's how I would have read it too.
Whereas AFAICT the `other libraries' referred to in the bug is just
celt. (The libdnet problem was fixed by an NMU in May.) And the real
problem is not a technical difficulty with roar but the decision of
the roar maintainers to link against celt. So in fact what is
happening here is that Ron is escalating the dispute about celt asking
other packages (here cmus) to remove the dependencies on roar. _If_
this is an appropriate way to escalate such a dispute at all, it
certainly should only be done with a message which makes it perfectly
clear what's going on.
Charitably, it seems that at the very least Ron needs to be much more
careful to fully disclose the situation when he makes requests which
are part of his prosecution of a dispute.
A less charitable interpretation would be that Ron was pretending to
an authority he did not have. That would be breach of trust, which is
serious because the whole project runs on trust. We trust that when
someone writes something that sounds like they're the maintainer of
foo, saying `please do X with regards to foo', they are actually
entitled to make that request.
I think the fact that he appears to have been right about roaraudio on
a technical level is no excuse.
But none of this is a good reason for trying to undo those changes at
this stage. And I think an TC resolution on this subtopic is
unlikely. So while I wanted to put all the above on the record, there
may be little more to be done about it by the TC. (I have CC'd
leader@ in case they want to take this up.)
So in summary, having done a bit of research, I agree that the TC
should now restrict the scope of our enquiry to mumble.