Re: Distributing software written by hostile upstream developers
On Fri, Sep 11, 2009 at 10:11:54AM +0200, Stefano Zacchiroli wrote:
>On Thu, Sep 10, 2009 at 10:42:45PM +0200, Joerg Jaspert wrote:
>> > In my opinion, the current recommendation in the developer
>> > references is enough for now:
>> Different thing. This encourages the maintainer to think if he wants
>> it. Now, what if the maintainer wants it (hey, some people might like
>> some pain), but a huge group in Debian does not? The latter is what
>> Steve tries to address, the dev-ref doesnt do any good there.
>Still, I fail to see exactly how Steve was proposing to solve the
>issue. He mentioned a vote, but to me the proposal was too vague to even
>understand what we can vote about.
Oh, absolutely. :-) I don't have a concrete proposal for what we
could/should vote on yet, instead I'm looking for more opinions here.
>Actually, I don't even think we need a _general_ solution for the cases
>you mention (which are at least a bit more precise enabling to
>understand what we are talking about). In those cases indeed, we would
>have a conflict between a single developer and the "developer
>body". Cases like that are already supported by constitution per se by,
>for instance, having a GR (or even appealing to CTTE FWIW).
>One might think that the GR is "too public" and that can exacerbate the
>battle between the project and the upstream author, but actually in all
>past cases that come to my mind, the battle was already well known to
>the big public.
>So, can't we just stay put and say that, when new cases will arise, we
>will vote about whether the project wants a specific software---due to
>difficulties in dealing with a specific upstream---in the distro or not?
I guess it depends on how often it might come up; do we need a YA
potential flamwewar each time, or can we come up with a set of
reasonable guidelines which will help maintainers/ftpmaster/TC to
decide without that?
Steve McIntyre, Cambridge, UK. email@example.com
Welcome my son, welcome to the machine.