Sean Whitton dijo [Mon, Jan 09, 2017 at 07:08:19PM -0700]: > Title: State exception for security bugs in Social Contract clause 3 > (...)
I have been following this thread, and although four days might not seem like a long time, I feel that me comenting here is due. In this thread, Martin Bagge asked for some background to why Sean proposed this. I recently processed Sean for the New Member process. I must say, it is amazing that somebody with Sean's record of activity had not yet become a full DD! Anyway, while going through the interview with Sean, I did prompt him to submit this GR. I'm quoting from the NM process here only with Sean's implicit approval, as it was agreed to begin with that NM interviews are part of a public process: > > > I would also append a remark about security bugs to clause 3 of > > > the Social Contract. Sometimes known security bugs are kept > > > confidential until the security team can co-ordinate a release > > > with other vendors. It could be argued that this is an > > > exception to clause 3 of the Social Contract, so it would be > > > good to explain it there. > > > > Right, fair and good point. Worth thinking about and maybe > > submitting a clear, simple GR to patch the issue, I think. > > Cool, I've made a note to look into this in the future. And we should look into this and properly consider it, taking it beyond just the archiving of a NM application. Of course, I take it as my fault (maybe because I recognized Sean as quite active already in the project, overestimating his grip of our common practices and general views) that I didn't give enough background on similar experiences we had in the past (i.e. the long flamefest¹ that followed "Editorial amendments"² and that quite clearly delayed Sarge for over a year), which in turn explain why our community views GRs as something that should be very sparingly used. ¹ https://lists.debian.org/debian-devel/2004/04/thrd5.html#01929 https://lists.debian.org/debian-devel/2004/04/thrd5.html#01996 ² https://www.debian.org/vote/2004/vote_003 I recognize a GR is quite a bit of a burden, mainly to our dear project secretary. It also introduces a topic we should think and write about for quite a long timeframe. In private conversation, though, I told Sean I would like this to change — GRs should not be seen as something to always avoid if possible. At some point I remember seeing a pseudo-GR (that is, without official status, conducted by an individual other than the Project Secretary; I don't rememeber when this was, but that's not so relevant) for measuring the developers' shared opinion on a given subject. As you know, I am for fixing our defining documents when there is an impedance with truth; that's why I helped draft and supported Nicolas' GR¹ on declassifying debian-private and later resubmitted it². And, yes, that's why I offered Sean to second his GR. ¹ https://www.debian.org/vote/2016/vote_002 ² https://www.debian.org/vote/2016/vote_004 Now, the arguments that have been given so far regarding this topic are strong, and I do think I should have thought better my answers as an AM. I did feel a moral obligation to answer to this thread. I understand Sean must be frustrated by the lack of empathy to his drive for correcting reality impedance; maybe it should not be via an amendment to a foundation document, but by prominently enough (somebody please define "enough") clearly documenting that we adhere to reasonable embargo disclosure guidelines, such as the one mentioned by Russ.
signature.asc
Description: Digital signature