Re: Changing how we handle non-free firmware

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

ot object. -- Sean Whitton signature.asc Description: PGP signature

Re: Draft Amendment for Rationale Section

lly 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

@@ -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)

the wdiff does indeed correspond to the amendment text :-) -- Sean Whitton

Re: Possible third ballot option -- middle ground between choices (1) and (2)

ur 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 withi

Possible third ballot option -- middle ground between choices (1) and (2)

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;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

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

al 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 see

Re: Amendment to rms-open-letter GR

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.

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 r

Re: Amendment to GR on RMS rejoining FSF

flect 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

Amendment to rms-open-letter GR

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

Re: Willingness to share a position statement?

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 sign

Re: How can we make Debian packaging more standardised?

you want. -- Sean Whitton

Re: Q to all candidates: NEW queue

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

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

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?

d 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

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?

d in our mailing list archives. -- Sean Whitton signature.asc Description: PGP signature

Question to Jonathan: how do you intend to prioritise?

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

ions 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

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

Re: Proposal to overturn init systems premature GR

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

t 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 ne

Re: Proposal: Focus on systemd

ng 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

; 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

raging 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

t; >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

stemd 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

sc, 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

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

esn'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?

istically, 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?

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?

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

o 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 >> everyt

Re: Questions about "Winding down my Debian involvement"

t 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"

). 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

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

y/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.

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

er 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

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 s

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? --

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

ion 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

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