Re: The New Security Build Infrastructure
>>>>> "Stephen" == Stephen Stafford <email@example.com> writes:
Stephen> On Sat, Jun 08, 2002 at 11:34:59PM +0200, Florian Weimer
>> Anthony Towns <firstname.lastname@example.org> writes:
>> > The major difference is that security updates frequently
>> shouldn't be > made public as soon as they're ready;
>> By the way, handling security updates this way conflicts more
>> and more with the Social Contract in its current form.
Stephen> Didn't we already *have* this flamewar recently?
Yes and IMHO the arguments presented were poorly thought out; your
argument below is typical of the lack of logic employed in the
flamewar. I don't actually care enough about the issue to make a big
deal of it so I let things drop last time it happened. I'll be happy
to work with someone who wants to make this a big issue to at least
make sure they present rational arguments, but I have no interest in
starting the crusade myself or in being any significant part of it.
Stephen> This is the way it is with security, it is that way for
Stephen> some very good reasons. We either accept it, or we don't
Stephen> *get* the advance notice and chance to release security
Here you argue only that it is a good idea to hide security updates,
not that doing so is consistent with the social contract. Not all
right things are by their nature consistent with the particular
document we adopted as our social contract. While saying something is
right is an argument that we should do it, it does not speak to
whether that thing follows the social contract.
It is quite possible that both hiding security updates is good and
that doing so violates the social contract. People believing such
things should introduce a GR to change the social contract and allow
hiding of security updates.
Stephen> That *would* conflict with our social contract
Stephen> as it would most definitely *not* be looking after the
Stephen> best interests of our users.
Here you are proposing that we have latitude to violate the social
contract when its prohibitions conflict with its priorities. I think
if you are going to make this argument you need to flesh it out a bit
more. To suggest one potential problem, it might seem to some that
the needs of our users and the free software community are best met by
making compromises in other parts of the social contract, like the
claim that Debian will be 100% free software. I do have to work a bit
to come up with a case where including non-free software in Debian
would benefit the free software community, but I'm not sure that no
such case exists.
I think most of us agree that compromising on the freedom of Debian
would not be acceptable. So why is it acceptable to compromise on the
openness of Debian, or why shouldn't we explicitly state such a
compromise in the text of the social contract?
But whatever. Assuming there is no complexity behind an issue and
that it is just people randomly flaming--or even assuming that people
disagree with what you see as an obvious right thing to do because
they bring up issues--is easier than actually thinking about an issue
and putting effort into stating a well-reasoned position.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org