Re: Changing how we handle non-free firmware
Hello, On Mon 22 Aug 2022 at 12:32PM -05, Gunnar Wolf wrote: > > I hereby propose the following alternative text to Steve's original > proposal. > > I'm only suggesting to modify the third paragraph, offering to produce > two sets of images (fully-free and with-non-free-firmware), being the > later more prominent. > > = > > We will include non-free firmware packages from the > "non-free-firmware" section of the Debian archive on our official > media (installer images and live images). The included firmware > binaries will *normally* be enabled by default where the system > determines that they are required, but where possible we will include > ways for users to disable this at boot (boot menu option, kernel > command line etc.). > > When the installer/live system is running we will provide information > to the user about what firmware has been loaded (both free and > non-free), and we will also store that information on the target > system such that users will be able to find it later. The target > system will *also* be configured to use the non-free-firmware > component by default in the apt sources.list file. Our users should > receive security updates and important fixes to firmware binaries just > like any other installed software. > > While we will publish these images as official Debian media, they will > *not* replace the current media sets that do not include non-free > firmware packages, but offered alongside. Images that do include > non-free firmware will be presented more prominently, so that > newcomers will find them more easily; fully-free images will not be > hidden away; they will be linked from the same project pages, but with > less visual priority. > > = Seconded. Many thanks to both Steve and Gunnar. -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote
Hello, On Thu 03 Mar 2022 at 01:54PM -07, Sam Hartman wrote: > I hereby amend the ballot option I proposed using the procedure in > Constitution section A.1. My understanding is that this amendment > replaces my ballot option unless one of the sponsors objects. Thanks. I do not object. -- Sean Whitton signature.asc Description: PGP signature
Re: Draft Amendment for Rationale Section
Hello, On Wed 02 Mar 2022 at 02:54PM -07, Sam Hartman wrote: > I'd like to update the rationale section of my GR to fix a typo and to > better explain the differences between this option and other ballot > options. If sponsors of my option do not have comments I intend to > formally amend my option tomorrow. Sponsors would then have an > additional 24-hours to object. Could we have a diff, please? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: GR: Hide Identities of Developers Casting a Particular Vote
e voting period is 2 weeks, but may be
> varied by up
>to 1 week by the Project Leader.
>
>
>
> @@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>
>
>
> Votes are cast[-by email-] in a manner suitable to the Secretary.
> The Secretary determines for each poll whether voters can change
> their votes.
>
> @@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
> necessary.
>
> The next two weeks are the polling period during which
> Developers may cast their votes. [-Votes in leadership elections are-]
> [- kept secret, even after the election is finished.-]{++}
>
> The options on the ballot will be those candidates who have
> nominated themselves and have not yet withdrawn, plus None Of The
--
Sean Whitton
signature.asc
Description: PGP signature
Re: GR: Change the resolution process (2021-12-12 revision)
Hello, On Sun 12 Dec 2021 at 01:09pm -08, Russ Allbery wrote: > This is the wdiff of my proposal against the previous version so that > people can easily (maybe?) see what changed since the last published > version. FWIW I've reviewed this and am happy with the amendment, assuming the wdiff does indeed correspond to the amendment text :-) -- Sean Whitton
Re: Possible third ballot option -- middle ground between choices (1) and (2)
Hello Wouter, On Mon 29 Nov 2021 at 10:34PM +02, Wouter Verhelst wrote: > You may of course do so, but I think it creates a system that > incorporates the worst of both worlds. My proposed system allows one to > extend the time at all time (while making it progressively harder as > time goes on), because I believe it is better to have a system that > allows that flexibility when necessary than to have a system with a > rigid, unchangeable limit. > > If you *do* prefer that limit, then I think it makes more sense to have > a system like Russ's, where time is extended when a ballot option is > added, but not past your time limit. His system is procedurally much > simpler than mine, but has the downside that it creates what I think is > an unacceptable hard limit. If you believe three weeks is too short, > might it not be better to propose a system like Russ's, but with the > hard limit at four weeks rather than three? > > I don't really like the procedural complexity that my system creates, > but I think that disadvantage outweighs the disadvantage that the rigid > limit in Russ's proposal creates. Belated thank you for your feedback. No-one else has spoken up in a way which suggests they'd second my proposal, so I'm not going to pursue it. If Russ's proposal is the one we end up adopting, one possibility is that we have another GR simply to increase the limits a bit, after we've had some experience working within the new procedure. -- Sean Whitton signature.asc Description: PGP signature
Possible third ballot option -- middle ground between choices (1) and (2)
Dear all, I am interested in this informal proposal from Russ, which has not received much explicit feedback: On Sun 07 Nov 2021 at 03:53PM -08, Russ Allbery wrote: > I wonder if you could make the system even simpler, producing a scheme > that has some admirable simplicity advantages over my proposal. > Something like this: > > 1. The discussion period starts when a draft resolution is proposed and >sponsored. The length of the discussion period starts at 1 week. > > 2. An extension to the discusison period may be proposed and sponsored >according to the requirements for a new resolution. As soon as a >discussion period extension reaches the required number of sponsors, it >takes effect and cannot be withdrawn. > > 3. The first two times the discussion period is extended add an additional >week to the length of the discussion period. Subsequent extensions add >an additional 72 hours. > > 4. The proposer and sponsors of an extension to the discussion period may >not propose or sponsor any additional extensions to the discussion >period for the same General Resolution. > > 5. The discussion period may not be extended beyond six weeks. > > and then drop not only the language about extending the discussion period > when the ballot changes but also all the language for the DPL varying the > length of the discussion period, and use this system as the only mechanism > for changing the length of the discussion period. I have been studying Wouter's formal proposal and believe that the only substantive difference with the quoted text is that where the quoted text has a hard limit on the discussion period, Wouter's proposal instead has a mechanism for objecting to further extensions. Would someone else be able to confirm this reading, please? If I'm right, I am considering proposing a third choice which is identical to Wouter's, except it would drop the mechanism for objecting to extensions beyond four weeks and reimpose a maximum discussion period, which I am thinking of setting to four weeks. I think this is a good middle ground between the two proposals we have so far. This third proposal - is procedurally simple - incorporates Russ's concern about overly long discussion periods, with a maximum that is only a little bit longer than his - incorporates the idea that three weeks is very short in Debian terms - should still allow the project to respond quickly when we mostly agree. Many thanks to Russ and Wouter for all their work on this. -- Sean Whitton signature.asc Description: PGP signature
Re: GR: Change the resolution process (2021-11-25 revision)
t causes the discussion period to end within 48 >hours of when this change is made. The length of the discussion >period is then recalculated as if the new minimum and maximum >lengths had been in place during all previous ballot changes under >points A.1.1 and A.1.4. > > 7. The default option has no proposer or sponsors, and cannot be >amended or withdrawn. > > A.2. Withdrawing ballot options > > 1. The proposer of a ballot option may withdraw. If they do, new >proposers may come forward to keep the ballot option alive, in >which case the first person to do so becomes the new proposer and >any others become sponsors if they aren't sponsors already. Any new >proposer or sponsors must meet the requirements for proposing or >sponsoring a new resolution. > > 2. A sponsor of a ballot option may withdraw. > > 3. If the withdrawal of the proposer and/or sponsors means that a >ballot option has no proposer or not enough sponsors to meet the >requirements for a new resolution, and 24 hours pass without this >being remedied by another proposer and/or sponsors stepping >forward, it is removed from the draft ballot. This does not change >the length of the discussion period. > > 4. If all ballot options except the default option are withdrawn, the >resolution is canceled and will not be voted on. > > A.3. Calling for a vote > > 1. After the discussion period has ended, the Project Secretary will >publish the ballot and call for a vote. The Project Secretary may >do this immediately following the end of the discussion period and >must do so within five days of the end of the discussion period. > > 2. The Project Secretary determines the order of ballot options. At >their discretion they may reword the single-line summaries for >clarity. > > 3. Minor changes to ballot options under point A.1.5 may not be made >after or within 24 hours of the end of the discussion period unless >the Project Secretary agrees the change does not alter the meaning >of the ballot option and (if it would do so) warrants delaying the >vote. The Project Secretary will allow 24 hours for objections >after any such change before issuing the call for a vote. > > 4. No new ballot options may be proposed, no ballot options may be >amended, and no proposers or sponsors may withdraw within 24 hours >of the end of the discussion period unless this action successfully >extends the discussion period under point A.1.4 by at least 24 >additional hours. > > 5. Actions to preserve the existing ballot may be taken within 24 >hours of the end of the discussion period, namely a sponsor >objecting to an amendment under point A.1.3, a Developer objecting >to a minor change under point A.1.5, stepping forward as the >proposer for an existing ballot option whose original proposer has >withdrawn it under point A.2.1, or sponsoring an existing ballot >option that has fewer than the required number of sponsors because >of the withdrawal of a sponsor under point A.2.2. > > 6. The Project Secretary may make an exception to point A.3.4 and >accept changes to the ballot after they are no longer allowed, >provided that this is done at least 24 hours prior to the issuance >of a call for a vote. All other requirements for making a change to >the ballot must still be met. This is expected to be rare and > should only be done if the Project Secretary believes it would be >harmful to the best interests of the project for the change to not >be made. > > A.4. Voting procedure > > 1. Options which do not have an explicit supermajority requirement >have a 1:1 majority requirement. The default option does not have >any supermajority requirements. > > 2. The votes are counted according to the rules in section §A.5. > > 3. In cases of doubt the Project Secretary shall decide on matters of >procedure. > > Strike section A.5 in its entirety. > > Rename section A.6 to A.5. > > Replace the paragraph at the end of section A.6 (now A.5) with: > > When the vote counting mechanism of the Standard Resolution Procedure > is to be used, the text which refers to it must specify who has a > casting vote, the quorum, the default option, and any supermajority > requirement. The default option must not have any supermajority > requirements. -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
Hello, On Tue 30 Mar 2021 at 11:28PM +01, Jonathan Wiltshire wrote: > CHOICE TEXT FOLLOWS: > > This is a position statement of the Debian Developers in accordance with > our constitution, section 4.1.5. > > The Developers firmly believe that leaders in any prominent organisation > are, and should be, held to the highest standards of accountability. > > We are disappointed that issues of transparency and accountability in the > governance of the Free Software Foundation have led to unresolved and > serious complaints of impropriety by its founder Richard Stallman over a > number of years whilst in the position of president and as a member of the > board. In particular, we are deeply concerned that the board saw fit to > reinstate him without properly considering the effect of its actions on > those complainants. > > The Developers acknowledge that people make mistakes but believe that where > those people are in leadership positions, they must be held accountable for > their mistakes. We believe that the most important part of making mistakes > is learning from them and changing behaviour. We are most concerned that > Richard and the board have not sufficiently acknowledged or learned from > issues which have affected a large number of people and that Richard > remains a significant influence on both the FSF board and the GNU project. > > We call upon the Free Software Foundation to further steps it has taken in > March 2021 to overhaul governance of the organisation, and to work > tirelessly to ensure its aim is fulfilled. We believe that only through > properly accountable governance can members of an organisation ensure their > voice is heard. The Free Software Foundation must do everything in its > power to protect its staff and members, and the wider community, including > a robust and transparent process for dealing with complaints. > > We urge Richard Stallman and the remaining members of the board which > reinstated him, to consider their positions. > > The Developers are proud that contributors to free software come from all > walks of life and that our diverse experience and opinions are a strength > of software freedom. But we must never cease in our efforts to ensure that > all contributors are treated with respect, and that they feel safe and > secure in our communities - including when we meet in person. > > END CHOICE TEXT Seconded. -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to rms-open-letter GR
Hello, On Thu 25 Mar 2021 at 10:33PM +01, Stefano Zacchiroli wrote: > On Thu, Mar 25, 2021 at 10:50:37PM +0200, Jonathan Carter wrote: >> I'm not sure I like this. I believe that removing the board is a >> critical part of the letter. They are 4 friends that RMS chooses that he >> chose because they never appose him. They are not elected by members of >> the FSF but a self-selected cabal. > > As one of the first signers, but speaking solely for myself, I can > confirm that recalling the entire board was for me a critical part of > the letter. The rationale being that reinstating him shows a severe lack > of judgment on the part of the board (technically: on the voting > members, but that's an implementation detail which I thought would be > lost on 99% of the letter readership and hence was in favor to leave > out) and institutional failure, which cannot be cured by simply undoing > the decision. > > (Of course a statement by the Debian project, in there is going to be > one, can take a different stance.) Can I ask why you didn't call for the recall of all of the voting members rather than just the board? It seems there are voting members who are not on the board? -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to rms-open-letter GR
Hello Jonathan, On Thu 25 Mar 2021 at 10:50PM +02, Jonathan Carter wrote: > I'm not sure I like this. I believe that removing the board is a > critical part of the letter. They are 4 friends that RMS chooses that he > chose because they never appose him. They are not elected by members of > the FSF but a self-selected cabal. > > I'm not sure what the plans would be if the board would actually resign, > clearly RMS and the board have no intention of doing so (at least by > their choice of language in that announcement), but ideally the board > would be selected by the community and be held accountable by them, > currently they answer to no one and let RMS do whatever he feels like > without consequences. Thank you for the input. At least one board member who voted against the readmission of Stallman has resigned, and it would seem that the vote was actually among all the voting members, which includes the board. So it seems things are quite complicated -- should the call be for all the existing voting members to be replaced? I'm not sure, which is why I suggested just saying something about what's most important, which is the removal of rms. -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to rms-open-letter GR
Hello, On Thu 25 Mar 2021 at 01:17PM -07, Sean Whitton wrote: > The point of this is not to call for the removal of the entire FSF > board, as the open letter does, while still supporting the main thrust > of the open letter, which is about Stallman himself. > > The vote to restore Stallman to the board was not unanimous, and there > is some confusion about how the procedure for elections to the board > actually works, so the call to remove *all* board members does not make > sense to me. And the FSF is going to need people with experience to > help it recover from this whole affair. > > There are probably others who think similarly to me about the call to > remove the whole board, so this amendment gives them something to vote > for in preference to just signing the open letter. It's an alternative > rather than a rival. Sruthi's new amendment doesn't make specific calls w.r.t. what the future organisation of the FSF should be, so it achieves the purposes I had in writing my amendment. I'm not going to withdraw my amendment because it seems like some people want to vote for it, but I will probably not be ranking it first myself. -- Sean Whitton signature.asc Description: PGP signature
Re: Amendment to GR on RMS rejoining FSF
Hello, On Sat 27 Mar 2021 at 12:17AM +0530, Sruthi Chandran wrote: >> Begin text >> >> Under section 4.1.5 of the constitution, the Developers make the >> following statement: >> >> *Debian’s statement on Richard Stallman rejoining the FSF board* >> >> We at Debian are profoundly disappointed to hear of the re-election of >> Richard Stallman to a leadership position at the Free Software >> Foundation, after a series of serious accusations of misconduct led to >> his resignation as president and board member of the FSF in 2019. >> >> One crucial factor in making our community more inclusive is to >> recognise and reflect when other people are harmed by our >> own actions and consider this feedback in future actions. The way >> Richard Stallman announced his return to the board unfortunately lacks >> any acknowledgement of this kind of thought process. We are deeply >> disappointed that the FSF board elected him a board member again despite >> no discernible steps were taken >> by him to be accountable for, much less make amends for, his past >> actions or those who have been harmed by them. Finally, we are also >> disturbed by the secretive process of his re-election, and how it was >> belately conveyed [0] to FSF’s staff and supporters. >> >> >> We believe this step and how it was communicated sends wrong and hurtful >> message and harms the future of the Free Software movement. The goal of >> the software freedom movement is to empower all people to control >> technology and thereby create a better society for everyone. Free >> Software is meant to serve everyone regardless of their age, ability or >> disability, gender identity, sex, ethnicity, nationality, religion or >> sexual orientation. This requires an inclusive and diverse environment >> that welcomes all contributors equally. Debian realises that we >> ourselves and the Free Software movement still have to work hard to be >> in that place where everyone feels safe and respected to participate in >> it in order to fulfil the movement's mission. >> >> >> That is why, we call for his resignation from all FSF bodies. The FSF >> needs to seriously reflect on this decision as well as their >> decision-making process to prevent similar issues from happening again. >> Therefore, in the current situation we see ourselves unable to >> collaborate both with the FSF and any other organisation in which >> Richard Stallman has a leading position. Instead, we will continue to >> work with groups and individuals who foster diversity and equality in >> the Free Software movement in order to achieve our joint goal of >> empowering all users to control technology. Seconded. -- Sean Whitton signature.asc Description: PGP signature
Amendment to rms-open-letter GR
Hello, Seeking seconds: ===BEGIN Replace the entire text with: Under section 4.1.5 of the constitution, the Developers make the following statement: The Debian Project echoes and supports recent calls to remove Richard M. Stallman from positions of leadership within free software, for which we believe him to be inappropriate. We are disappointed by the actions of those responsible for restoring him to the Free Software Foundation's Board of Directors, and urge that that decision be reversed. ===END The point of this is not to call for the removal of the entire FSF board, as the open letter does, while still supporting the main thrust of the open letter, which is about Stallman himself. The vote to restore Stallman to the board was not unanimous, and there is some confusion about how the procedure for elections to the board actually works, so the call to remove *all* board members does not make sense to me. And the FSF is going to need people with experience to help it recover from this whole affair. There are probably others who think similarly to me about the call to remove the whole board, so this amendment gives them something to vote for in preference to just signing the open letter. It's an alternative rather than a rival. I see that some people have raised concerns about the appendix to the open letter. I haven't formed an opinion about that myself yet, but perhaps this amendment could be something for such individuals to vote for, too. -- Sean Whitton signature.asc Description: PGP signature
Re: Willingness to share a position statement?
Hello Martin, On Thu 25 Mar 2021 at 06:15PM +01, Martin Pitt wrote: > As this is is a highly political, divisive, and personal topic, not a > technical one, I'd really hope that this would be a secret vote, much > like the Debian leader voting? It's not technical indeed, but I think it would be a mistake to think that what is going on here is only general political activism. Rather, this is about the leadership of a /particular/ political movement, the free software movement, and there can't really be any doubt that Debian is a part of /that/ movement. -- Sean Whitton signature.asc Description: PGP signature
Re: How can we make Debian packaging more standardised?
Hello Jonathan, On Mon 22 Mar 2021 at 07:57PM +02, Jonathan Carter wrote: > I admit I don't know how to use either properly and have somehow > managed to get away with it, but I do plan on learning how to use dgit > if I can find a good primer on it dgit-maint-gbp(7) is probably what you want. -- Sean Whitton
Re: Q to all candidates: NEW queue
Hello Martin, On Fri 27 Mar 2020 at 12:23PM +01, Martin Pitt wrote: > At least during my many years of Ubuntu archive administration I've actually > seen quite a lot of packages which contained non-distributable files, had > hilariously broken maintainer scripts (which could then also damage *other* > software on your system), and the like. For these an initial NEW review was > quite important. Indeed. > @ftpmasters, would it help to try some automation on the 80% case, and e. g. > auto-process packages if they are lintian-clean, suspicious-source is empty, > and checking for some reasonable overlap of licensecheck and grep -i '(c)' > with > names appearing in debian/copyright? So that ftpmasters can concentrate on the > 20% complicated packages? > > Or are the 80% already not a problem/time sink? They're not a problem. They only get stuck for too long sometimes because the code which chooses which order to display the packages to us sometimes puts them much lower down in the queue than you'd expect them to me, for reasons I don't yet understand. -- Sean Whitton signature.asc Description: PGP signature
Re: Q to all candidates: NEW queue
Hello, On Fri 27 Mar 2020 at 09:39AM +01, Ulrike Uhlig wrote: > My point was to ask if there are any points in this list that could be > harmful in the scenario proposed by Lucas. We try to stop packages of sufficiently low quality entering the archive at all, so that other contributors don't have to deal with understanding what's going on with those low quality packages when trying to fix other stuff. I would say that Lucas' proposal would not be able to achieve that. -- Sean Whitton signature.asc Description: PGP signature
Re: Q to all candidates: NEW queue
Hello Roberto, On Thu 26 Mar 2020 at 09:51AM -04, Roberto C. Sánchez wrote: > Good point. The most recent experience I had with this was a package I > uploaded in February 2019. The FTP team rejection came on 4th January > 2020, my requests for additional clarification were made within 24 hours > of the rejection, but have not yet been replied to by the FTP team. Typically we try to follow up on requests for clarification but sometimes e-mails get lost. So kindly ask again. > I have filed an ITP for every new package I have ever uploaded. I have > never seen the FTP team make comments in the ITP bug whenever there has > been an issue that had to be resolved, and that remains the case for my > most recent experience. The FTP Team has not adopted the workflow of posting comments to ITPs. -- Sean Whitton signature.asc Description: PGP signature
Re: Question to Jonathan: how do you intend to prioritise?
Hello Jonathan, On Tue 17 Mar 2020 at 12:21PM +02, Jonathan Carter wrote: > Great question, thanks! I'll try to explain it without throughing more > bullet points at you while at the same time navigating all the clichés > that exist for so many good reasons. Thanks, this e-mail helps a lot. > By the end of the term, I would like to have a shared sense of 'business > as usual' within the project. I'd like our contributors and project > members to have a sense of belonging, and that they can focus on their > work and improve Debian's technical excellence without having to spend > too much time on unproductive drama. I know that sounds incredibly > broad, and at the same time somewhat vague, but I believe it's what the > project needs right now. I agree that this would be beneficial for us. Perhaps the thing to do would be for the DPL to seek out and amplify small efforts people are making in this direction. -- Sean Whitton signature.asc Description: PGP signature
Question for all candidates: Sam's non-platform: Delegates
Hello, In his non-platform, Sam wrote If I were running as DPL, figuring out how to do a better job of managing delegations, respecting both the current delegates and the needs of the project, would be my priority for the next year. I hope that the candidates who step forward take on this challenge. Do you agree? If so, how do you propose to take on the challenge? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: What are your thoughts on discourse?
Hello, On Wed 18 Mar 2020 at 11:00AM +01, Raphael Hertzog wrote: > Hello dear DPL candidates, > > I would like all the candidates to reply to this question on discourse: > https://discourse.debian.net/t/dear-dpl-candidates-what-are-your-thoughts-on-discourse/75 > > Please create an account and answer there. At least it would give you a > feeling of how it looks like to use it. Candidates, could you please copy your answers into replies to this mail please? I don't mind clicking on a link to read the answers too much, but I think your answers should be preserved in our mailing list archives. -- Sean Whitton signature.asc Description: PGP signature
Question to Jonathan: how do you intend to prioritise?
Dear Jonathan, It is good that you have shared with us all, in your platform, your broad vision for what it is most important for the project to address. No-one could reasonably expect you to complete everything there in a single term, but it helps us choose how to vote if we have a more complete idea of where you think the project stands. I would also like to know, however, what you seek to prioritise -- which parts of your platform are a matter of you sharing with us your long term vision, and which parts do you actively plan to accomplish in the next twelve months? Right now, the most concrete part of your platform is pushing forward changing our nomenclature for project members. So when I reached the end of your platform, it seemed to me that this was the only thing in it I could be sure you intend to pursue, if elected, over the next year. And surely this was not the impression you intended the platform to have on your readers :) Please help me get a more concrete idea of what sort of project-level changes I could expect you to attempt if you were elected. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Re: Last minute cominbations G+D and/or G+E
es have to evaluate technical > contributions intended to support non-systemd users. The acceptability to > users > of non-default init systems, of quality risks of such contributions, is a > matter for the maintainers of non-default init systems and the surrounding > community. But such contributions should not impose nontrivial risks on users > of the default configuration (systemd with Recommends installed). > > NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES > > 12. systemd provides a variety of facilities besides daemon startup. For > example, creating system users or temporary directories. Current Debian > approaches are often based on debhelper scripts. > > In general more declarative approaches are better. Where > > - systemd provides such facility > - a specification of the facility (or suitable subset) exists > - the facility is better than the other approaches available in Debian, for > example by being more declarative > - it is reasonable to expect developers of non-systemd systems including > non-Linux systems to implement it > - including consideration of the amount of work involved > > the facility should be documented in Debian Policy (by textual incorporation, > not by reference to an external document). The transition should be smooth for > all users. The non-systemd community should be given at least 6 months, > preferably at least 12 months, to develop their implementation. (The same goes > for any future enhancements.) > > If policy consensus cannot be reached on such a facility, the Technical > Committee should decide based on the project's wishes as expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 13. In general, maintainers of competing software, including maintainers of > the > various competing init systems, should be accommodating to each others' needs. > This includes the needs and convenience of users of reasonable non-default > configurations. > > 14. Negative general comments about software and their communities, including > both about systemd itself and about non-systemd init systems, are strongly > discouraged. Neither messages expressing general dislike of systemd, nor > predictions of the demise of non-systemd systems, are appropriate for Debian > communication fora; likewise references to bugs which are not relevant to the > topic at hand. > > Communications on Debian fora on these matters should all be encouraging and > pleasant, even when discussing technical problems. We ask that communication > fora owners strictly enforce this. > > 15. We respectfully ask all Debian contributors including maintainers, Policy > Editors, the Release Team, the Technical Committee, and the Project Leader, to > pursue these goals and principles in their work, and embed them into documents > etc. as appropriate. (This resolution is a position statement under s4.1(5).) -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: Focus on systemd
Hello, On Sun 01 Dec 2019 at 11:06AM +02, Martin Michlmayr wrote: > I'm sorry for the delay. Maybe this reply is moot now that proposal C > has been withdrawn but I wanted to share my personal view of why > another proposal was needed. > > [...] > > Like I said, proposals B and D have a lot of values that you can agree > with. Proposal C doesn't have any what I originally described as > "passion". When talking to other people I realized that proposal C > lacks "vision". Proposals B/D have much more of that > passion/values/vision. > > So looking at the proposals, I just found the offering a bit skewed > because I felt that the proposal that a lot of people want has no > "sway" in comparison with some of the other proposals. > > I hope that explains it. It does -- thanks, to you and to the others who responded to my question. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal to overturn init systems premature GR
Hello, On Tue 03 Dec 2019 at 04:15PM +00, Ian Jackson wrote: > We can do this with enough time to vote before Christmas, as Russ > reasonably points out is desirable. Russ suggested a voting period > starting on the 8th of December would be the latest sensible [2], > which probably means a call for votes the previous day. Russ, could you chime in here -- do you still think that starting on the 8th would give enough time to people who might be away from the PGP keys during the holiday season, or would we be cutting it tight? (I am almost never away from my own PGP subkeys so I don't feel I can judge myself whether it would be enough time.) -- Sean Whitton signature.asc Description: PGP signature
Re: Review of proposals
Hello, On Fri 29 Nov 2019 at 10:00PM -08, Russ Allbery wrote: > Speaking as one of the Policy editors, personally I'd rather have the > explicit time frame so that we don't have to argue about what "enough > time" means. I like Ian's explicit list, which preempts a lot of the > expected arguments. Speaking as the other Policy Editor, I concur. Ian's proposal is a powerful compromise because of its preemption of certain points of disagreement. For similar reasons, I don't think that Guillem's new proposal is sufficient to answer the project's current needs. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: Focus on systemd
Hello Martin, and seconders of proposal F, On Fri 29 Nov 2019 at 10:16PM +02, Martin Michlmayr wrote: > I'd like submit the following proposal: > > Proposal: Focus on systemd to promote standardization and > cross-distribution cooperation I would be grateful for an informal summary of why proposal F is thought to be needed on the ballot in addition to proposal C. What is thought not captured well by Sam's text, but is thought to be captured well by Martin's text? I don't mean to challenge the idea that proposal F is needed in addition to proposal C. I am just hoping to better understand the motivations behind proposal F than what I've been able to glean by putting the texts of proposals C and F side-by-side. -- Sean Whitton signature.asc Description: PGP signature
Re: CFV Timing and length of voting period
Hello, On Tue 26 Nov 2019 at 08:47AM -05, Sam Hartman wrote: > One question. Should I extend the voting period to give people more > time to vote given that holidays are near. I'm not sure it would help > much because I think the primary effect of doing that would be to extend > the voting period into the middle of the holidays. But if people think > it might help and would not be harmful I'm happy to do so. I'd go for it -- it might allow a few more people to vote and surely couldn't do any harm to anything. -- Sean Whitton signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES > > 9. systemd provides a variety of facilities besides daemon startup. >For example, creating system users or temporary directories. >Current Debian approaches are often based on debhelper scripts. > >In general more declarative approaches are better. Where > - systemd provides such facility > - a specification of the facility (or suitable subset) exists > - the facility is better than the other approaches available >in Debian, for example by being more declarative > - it is reasonable to expect developers of non-systemd >systems including non-Linux systems to implement it > - including consideration of the amount of work involved >the facility should be documented in Debian Policy (by textual >incorporation, not by reference to an external document). The >transition should be smooth for all users. The non-systemd >community should be given at least 6 months, preferably at least 12 >months, to develop their implementation. (The same goes for any >future enhancements.) > >If policy consensus cannot be reached on such a facility, the >Technical Committee should decide based on the project's wishes as >expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 10. In general, maintainers of competing software, including >maintainers of the various competing init systems, should be >accomodating to each others' needs. This includes the needs and >convenience of users of reasonable non-default configurations. > > 11. Negative general comments about software and their communities, >including both about systemd itself and about non-systemd init >systems, are strongly discouraged. Neither messages expressing >general dislike of systemd, nor predictions of the demise of >non-systemd systems, are appropriate for Debian communication fora; >likewise references to bugs which are not relevant to the topic at >hand. > >Communications on Debian fora on these matters should all be >encouraging and pleasant, even when discussing technical problems. >We ask that communication fora owners strictly enforce this. > > 12. We respectfully ask all Debian contributors including maintainers, >Policy Editors, the Release Team, the Technical Committee, and the >Project Leader, to pursue these goals and principles in their work, >and embed them into documents etc. as appropriate. >(This resolution is a position statement under s4.1(5).) > > -8<- -- Sean Whitton signature.asc Description: PGP signature
Re: Re-Proposing: General Resolution on Init Systems and systemd
in Debian, for example by being more declarative > - it is reasonable to expect developers of non-systemd >systems including non-Linux systems to implement it > - including consideration of the amount of work involved >the facility should be documented in Debian Policy (by textual >incorporation, not by reference to an external document). The >transition should be smooth for all users. The non-systemd >community should be given at least 6 months, preferably at least 12 >months, to develop their implementation. (The same goes for any >future enhancements.) > >If policy consensus cannot be reached on such a facility, the >Technical Committee should decide based on the project's wishes as >expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 10. In general, maintainers of competing software, including >maintainers of the various competing init systems, should be >accomodating to each others' needs. This includes the needs and >convenience of users of reasonable non-default configurations. > > 11. Negative general comments about software and their communities, >including both about systemd itself and about non-systemd init >systems, are strongly discouraged. Neither messages expressing >general dislike of systemd, nor predictions of the demise of >non-systemd systems, are appropriate for Debian communication fora; >likewise references to bugs which are not relevant to the topic at >hand. > >Communications on Debian fora on these matters should all be >encouraging and pleasant, even when discussing technical problems. >We ask that communication fora owners strictly enforce this. > > 12. We respectfully ask all Debian contributors including maintainers, >Policy Editors, the Release Team, the Technical Committee, and the >Project Leader, to pursue these goals and principles in their work, >and embed them into documents etc. as appropriate. >(This resolution is a position statement under s4.1(5).) > > - -8<- -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: General Resolution on Init Systems and systemd Facilities
Hello, On Fri 15 Nov 2019 at 10:03AM -08, Russ Allbery wrote: > I think I would rather have the clear path forward your proposal lays out, > with a 6-12 month delay, than to have my options B or C that set up Policy > discussions for each new feature while maintainers move forward in advance > of Policy. I think all these options can be made to work, but your > proposal, as well as options A and D from my original message, are much > cleaner and more straightforward and I think would lead to less arguing > and fewer demands on the Policy process. I agree with this assessment that Ian's proposal would allow the Policy process to get more done, in the sense of both building and documenting project consensus. I appreciate that, from the point of view of a proponent of new systemd features, this getting more done in Policy will seem to be in tension with getting more done in the archive. As a counterpoint to that, I think that the Policy process is an important part of how we get things done in the archive in the longer term, and Ian's proposal speaks to that. If we found that the six month delay was repeatedly expiring with no serious attempts at non-systemd implementations of the new features, we could repeal this GR. -- Sean Whitton signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
Hello, On Fri 08 Nov 2019 at 06:04PM +01, Ansgar wrote: > No, but maybe I expressed myself badly: we have people that complain > that building Debian source packages with a Debian-specific command is a > too high burden. This is independent of how source is represented (Git, > .dsc, rpm, Git+LFS, only-debian/-Git+tar, references to external > artifacts, ...). > > So some people believe that "Debian-specific tooling is bad", even for > Debian-specific work. Thanks for the clarification -- I see what you mean now. -- Sean Whitton signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
Hello, On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote: > We already have people complaining that source packages are "too Debian > specific" and should be replaced. The tooling above is even more of a > problem as third parties currently have to deal with way too many > different ways to even before getting to packaging which is inherently > more package-manager- and thus distribution(-familiy)-specific. If you're referring to those of us who aren't keen on the .dsc transport format, I think that the point is orthogonal. What we're talking about in this thread is the contents of binary packages. The reasons that there might be for reducing the amount of Debian-specific stuff in binary packages are quite different from the reasons for reducing the amount of Debian-specific stuff used in moving source code around. The basic reason for that is that what we are trying to produce is an operating system composed, roughly, of binary packages; we have produced ways to move source code around only incidentally to that. -- Sean Whitton signature.asc Description: PGP signature
Re: Bikeshedding
Hello,
On Wed 03 Apr 2019 at 12:51PM +01, Ian Jackson wrote:
> Stefano Zacchiroli writes ("Re: Bikeshedding"):
>> Statement: every Debian package must be maintained in Git on salsa and
>> every Debian Developer with upload rights to the archive should have
>> commit/push right to every packaging repository on salsa.
>>
>> DPL candidates: do you agree with this statement?
>> If so, what will be your approach to make this a reality?
>
> What git tree format do you mandate ?
>
> Such an imprecation is of little use if "maintained in git on salsa"
> means for some packages a giant packaging-only monorepo (like used by
> some language-specific packaging teams), for some a git-debrebase or
> git-dpm patches-applied tree, for some a merging git branch for use
> with 1.0-with-diff, and for some a gbp pq branch.
Yes. The amount of effort that we would need to expend on implementing
zack's Statement seems out of proportion to the benefit, given that it
mandates no particular git workflow.
> Another answer to this is:
>
> The git server you are asking about already exists. It is called
> `dgit.debian.org', not `salsa.debian.org'.
>
> It has the following properties:
>
> [...]
>
> So real answer is: everyone should consider `dgit push' and most
> people should be using it. It should be recommended in policy.
What's so nice about this is that it doesn't require anyone to
fundamentally change their git workflows (with the exceptions of people
who have only debian/ in their packaging repo (and Ian has experimental
patches for that case), and team monorepos).
You can incorporate `dgit push-source` into existing workflows and
achieve what (I think) zack and others want. See dgit-maint-gbp(1) etc.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Are Martin and Sam's platforms equivalent?
Hello, On Sun 31 Mar 2019 at 09:46PM +02, Jonathan Carter wrote: > Well, maybe you and I just fundamentally disagree on this one then. My > point was that if only 10 more DD's each took care of one more > sponsorship request of the last month, we'd now basically efficiently > have no backlog. As for your comment that additional tooling won't help, > I know it will help at least for me, because I check my QA pages often > because they're comprehensive, except for sponsorship requests. If they > were more prominent, then at least I would spend more opportunistic > attention to them. I certainly wasn't suggesting that DDs abandon some > of the deep-focus work that they're doing to do forced reviews, so, I > would not say that your summary is a fair representation of what I was > putting across. Fair enough, thanks. I don't look at QA summaries opportunistically, so I see why we'd have different impressions in this area. -- Sean Whitton signature.asc Description: PGP signature
Re: Are Martin and Sam's platforms equivalent?
Hello Jonathan, On Sat 30 Mar 2019 at 10:23AM +02, Jonathan Carter wrote: > That leaves less than 10 packages that need reviewing right now. I do > think that reviewing/sponsoring should be a lot better, and that more > DDs should play their part, and that our tooling can improve to bring > more visibility to these requests, but I would classify this more as a > medium priority problem TBH... hmm, am I being pedantic about > classification of problems... I digress.. > > More packages moving to teams have been a great thing for Debian, I > think we should leverage that more for sponsorship requests. It would be > nice if a DD looked at their DDPO page and it would also show > outstanding sponsorship requests for the teams they're part of. It's > great that the DDPO pages now show outstanding merge requests from salsa > in the VCS column, I would've probably missed the few MRs I've received > so far if it wasn't for that. > > If a quarter of active DDs checked the RFS list / mentors.debian.net > just once a month and reviewed a package, there would probably be no > problem in terms of waiting to get a package sponsored whatsoever, I > think we could do more to advertise the todo list, maybe a weekly report > to debian-devel like the WNPP report may work well. If I may summarise, your response is to invite more DDs to spend time reviewing sponsorship requests, and improve tooling a bit to reduce the friction in doing that; in particular, by pointing team members to sponsorship requests for packages that either are or will be maintained under the umbrella of that team. As I said in the message to which you're replying, I am not convinced that any tooling improvements are going to change the state of play in this area. So, then, your response is to ask more people to spend time on it. The problem with that is that it ignores the good reasons people have for not spending time on it! If I have relevant expertise or experience to improve Debian in some particular respect (e.g. fixing bugs in a packages written in a particular programming language that isn't so commonly used), I have strong reason to use my time to deploy that expertise and experience, rather than review some sponsorship requests. The latter very rarely requires skills not possessed by all DDs. Such reasons are defeasible, such as if I just really feel like reviewing sponsorship requests, but I think it's at the heart of the problem. We *all* have particular things we can do better than most other DDs, so we have strong reason to work on those, not on something that all of us can do. -- Sean Whitton signature.asc Description: PGP signature
Re: Are Martin and Sam's platforms equivalent?
Hello, On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote: > 1. Non-DDs getting single changes into Debian > If you are not a DD, there is no process to get a change into > Debian if the maintainer is MIA or is one of those maintainers > who ignores the BTS and only uploads new upstream versions. > Note that I am not talking about contoversial changes NAKed by the > maintainer, I am talking about 10 year old clearly correct patches > or "New upstream version" bugs that are rotting in the BTS. > Whether a patch is rotting in the BTS or is rotting in a MR on salsa > doesn't really make a difference on the underlying problem. I'm not sure about this -- there is the same NMU process everyone else uses, except that you need a sponsor. Which brings me to... > 2. Package sponsorship > Any mentoring outreach aimed at finding new contributors should start > with no longer frustrating the people who have already started to > contribute. They might stop their contributions. > There are too few people reviewing packages at sponsorship-requests, > but proper and timely reviews would be very important both for not > frustrating new contributors and ensuring that new contributors > are learning to do high-quality packaging. > Spending any resources on finding new contributors who are starting > at zero doesn't really make sense as long as people who are already > contributing have to wait months for getting their ITPs reviewed > and uploaded (and then have to wait additional months while the > package is in NEW). This is a huge problem, indeed. The two current processes that you identify as getting in newcomers' way -- RFS bugs and the NEW queue -- are slow simply because of the fact that both of them are understaffed. It's the usual problem with Debian not having the manpower we would like to have. The question is whether those processes could be changed such that the manpower problem would be less keenly felt. I cannot myself see any way to achieve that -- there are tooling issues but improving the relevant tools would not significantly speed either queue. -- Sean Whitton signature.asc Description: PGP signature
Re: Discussion on eventual transition away from source packages
Hello, On Fri 22 Mar 2019 at 09:32AM +01, Lucas Nussbaum wrote: > On 21/03/19 at 18:57 +0100, Joerg Jaspert wrote: >> Also, it will be a drastical change and has many far reaching >> consequences and needs lots of work nefore we are near it. > > I'm probably missing something, but it doesn't sound like a lot of work > to me? It's "just" a service that: > - gets notified of the existence of a git repo + tag to upload > - fetches that git repo + tag > - checks signature / confirm that the GPG key owner is allowed to upload > that package > - build a Debian source package > - uses a slightly different path to accept the source package (because > the .dsc and .changes wouldn't be signed) The problem is converting the git tree into a source package. The thousands of lines of code in dgit are a response to how hard it is to do that in sufficient generality (not full generality -- not even dgit does that). -- Sean Whitton signature.asc Description: PGP signature
Re: Questions about "Winding down my Debian involvement"
Hello, On Thu 21 Mar 2019 at 05:29PM +01, Joerg Jaspert wrote: > On 15348 March 1977, Sean Whitton wrote: > >> I won't write a long reply because it's not that important to the DPL >> election, but I did want to note that `dgit push-source` has answers for >> everything you've listed. I'd encourage you to take a(nother) look! > > Do those answers only apply if you still think of the traditional source > archives to upload, or also if one envisions to go away from that? The latter. `dgit push-source` treats both generating and uploading .dsc files as an implementation detail, basically transparent to the user. The big wrinkle is uploading binaries, which is not transparent, but moving to source-only uploads for everything, which is independently desirable, solves that. -- Sean Whitton signature.asc Description: PGP signature
Re: Questions about "Winding down my Debian involvement"
Hello, On Thu 21 Mar 2019 at 09:02AM +0100, Joerg Jaspert wrote: > Ideally you get an upload by a simple git push. `dgit push-source` is very nearly a simple git push. Your laptop FTPs stuff in the background, but that's transparent to the user. > Now we want to control a bit WHEN it uploads. > We also want some checks before the upload. > For legal reasons we do not want the full history (think of removed > undistributable files) in all cases. > > And so on. There are many points and I just list a tiny few. I won't write a long reply because it's not that important to the DPL election, but I did want to note that `dgit push-source` has answers for everything you've listed. I'd encourage you to take a(nother) look! -- Sean Whitton signature.asc Description: PGP signature
Re: Questions about "Winding down my Debian involvement"
Hello, On Wed 20 Mar 2019 at 04:17PM +01, Joerg Jaspert wrote: > I would actually like if we end up with a "git push turns into an > upload". Which would need some central $thing for it to make it so. Not > sure thats salsa. Or something seperately (but maybe together with it). We already have something that is quite close to this, in the form of `dgit push-source`. I am not really sure why people think some salsa CI thing would be better than that -- but would be grateful to know. -- Sean Whitton signature.asc Description: PGP signature
Re: Q to Mehdi: safe and fun
Dear Chris, On Wed, Mar 29, 2017 at 05:13:52PM +0100, Chris Lamb wrote: > I had a few long conversations on this topic in general recently with > folks like Nadia Eghbal, Deb Nicholson et. al which made me feel > optimistic that it is possible for free software culture to evolve. Could you share some of the reasons for your optimism? -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Thank you to Russ and Ben for the encouragement! On Sat, Jan 14, 2017 at 08:48:40AM +, Ian Campbell wrote: > You should read up on Coordinated (or Responsible) Disclosure vs. Full > Disclosure (not an uncontroversial topic in itself), the choice of > which one is used for a given bug is usually the choice of the > person/organisation who _discovers_ the issue. > [...] On Sat, Jan 14, 2017 at 11:47:17AM +0100, Emilio Pozuelo Monfort wrote: > Maybe there should be a note about how we handle embargoed vulnerabilities > here: > > https://www.debian.org/security/faq Thanks for reminding me about that existing FAQs page. I think that Ian's e-mail, suitably edited, would be a great addition if both Ian and the security team agreed. It could then be linked to from my new SocialContractFAQ page on the wiki. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
On Thu, Jan 12, 2017 at 04:39:05PM -0500, Scott Kitterman wrote: > That then has the opposite problem. It clearly narrows the notion of not > hiding problems and I don't think that's good either. Good point. > P.S. I am subscribed. Please don't cc me. Whoops, sorry about that. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Hello, On Fri, Jan 13, 2017 at 11:38:25AM -0600, Gunnar Wolf wrote: > 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. For the record, I do not take Gunnar to be at any fault here. However, it is true that had Gunnar not expected my GR to be uncontroversial, I probably wouldn't have proposed it. While I stand by my GR in principle, I agree with those who have said that it is not worth spending time on something like this unless it's going to pass without opposition. Since this GR /has/ turned out to be quite controversial, I hereby withdraw it. > 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. I just created this: https://wiki.debian.org/SocialContractFAQ My understanding of the policy that Russ linked to was that the security team are de facto bound to that policy because all the other distros are following it. Is that right? If so, it could be added to the new FAQ. After some polishing, maybe the WWW team could add a link to the new FAQ from the Social Contract itself. That would adequately respond to the reasons I had for proposing this GR: a newcomer who was particularly concerned about transparency would soon find their way to this page. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Hello Scott, On Tue, Jan 10, 2017 at 07:04:02PM -0500, Scott Kitterman wrote: > Yes, but all your proposed GR does is move the problem one definition > to the right. I don't follow this objection. The SC is not meant to contain exhaustive details of policies. At present, though, I think it goes too far the other way. This GR is intended to nudge it closer to the right level of detail. > Are you aware of any newcomers that have been negatively affected this > way? I'm not. I could imagine it happening to a younger version of myself, though. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Hello, On Wed, Jan 11, 2017 at 09:17:27AM +0100, Joerg Jaspert wrote: > Also, this is IMO nothing for a foundational document. But some docs > around it as explanation on how real world handles things. Do we have such a doc right now? Possibly somewhere on the wiki I'm unaware of? -- Sean Whitton signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Hello, In my original proposal e-mail, I should have said more about why I think this is a good idea. My apologies for not having done so. No-one who understands how GNU/Linux distributions work thinks that there is anything problematic about short-term embargos of information about serious security bugs. However, the SC is not just for those people: it's also something for newcomers to read. Imagine a newcomer who finds SC clause 3 very attractive: they particularly value transparency about development. Then they learn that certain information is held in a separate, non-public bug tracker, and their initial enthusiasm for Debian is somewhat dampened. If we pass this GR, we can avoid leaving a bad taste in that newcomer's mouth. That's good for Debian. On Mon, Jan 09, 2017 at 11:51:37PM -0500, Scott Kitterman wrote: > What is the definition of serious and what is the definition of > limited? Intentionally not specified, so that it's left up to the judgement of those implementing the social contract (i.e. the current body of developers, esp. the security team). The SC is full of words that work like this. -- Sean Whitton signature.asc Description: PGP signature
Proposed GR: State exception for security bugs in Social Contract clause 3
=== BEGIN GR TEXT === Title: State exception for security bugs in Social Contract clause 3 1. Debian has a longstanding practice of sharing information about serious security bugs with only the security team. This is so that they can co-ordinate release of the information with other vendors. 2. The third clause of our Social Contract says that "We will not hide problems." However, the practice of embargoing information about serious security bugs could be seen as the hiding of problems. 3. Resolve to append the following to clause 3 of the Social Contract: An exception is made for serious security problems. Information about these may be kept confidential for a limited period of time, so that a release of information may be co-ordinated with other vendors. === END GR TEXT === -- Sean Whitton signature.asc Description: PGP signature
