Re: General Resolution to deploy tag2upload
On Thu, Jun 27, 2024 at 03:15:42PM +0800, Sean Whitton wrote: > = > BEGIN FORMAL RESOLUTION TEXT > > tag2upload allows DDs and DMs to upload simply by using the > git-debpush(1) script to push a signed git tag. > > 1. tag2upload, in the form designed and implemented by Sean Whitton and >Ian Jackson, and design reviewed by Jonathan McDowell and Russ >Allbery, should be deployed to official Debian infrastructure. > > 2. Under Constitution ยง4.1(3), we overrule the ftpmaster delegate's >decision: the Debian Archive should be configured to accept and trust >uploads from the tag2upload service. > > 3. Future changes to tag2upload should follow normal Debian processes. > > 4. Nothing in this resolution should be taken as requiring maintainers >to use any particular git or salsa workflows. > > END FORMAL RESOLUTION TEXT > = Seconded. It's a shame we've come to a GR on this, but I do believe it adds a significant improvement to the git workflow when working in Debian. J. -- /-\ | "Oh, you are awesome when you're |@/ Debian GNU/Linux Developer | sarcastic. Please do carry on \- |:-)." -- iwj to rra on Ruby. signature.asc Description: PGP signature
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 09:28:53PM +0300, Adrian Bunk wrote: > Would you commit to something more specific, like that our Data > Protection team will reply to debian-project within 3 months discussing > all issues mentioned in the discussion at [1] so far, and with their > reply having been proof-read by our GDPR lawyer? If you had really cared about engaging with the data protection team and really believed the project was exposed to a lawsuit then the prudent thing would have been to initially contact the data protection team and DPL, rather than producing a long list of questions and stating that you didn't believe we are compliant with GDPR obligations and mailing it only to -project. If you have specific, concrete, concerns then perhaps you can state them, but it's hard to assume good faith when I don't see any sign that you're trying to actually help here. J. -- ] https://www.earth.li/~noodles/ [] Make friends.[ ] PGP/GPG Key @ the.earth.li[][ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Re: Re: Re-Proposing: General Resolution on Init Systems and systemd
[2019-11-16 18:18] Ian Jackson > - -8<- > > Title: Support non-systemd systems, without blocking progress > > PRINCIPLES > > 1. We wish to continue to support multiple init systems for the >foreseeable future. And we want to improve our systemd support. >We are disappointed that this has had to involve another GR. > > 2. It is primarily for the communities in each software ecosystem to >maintain and develop their respective software - but with the >active support of other maintainers and gatekeepers where needed. > > SYSTEMD DEPENDENCIES > > 3. Ideally, packages should should be fully functional with all init >systems. This means (for example) that daemons should ship >traditional init scripts, or use other mechanisms to ensure that >they are started without systemd. It also means that desktop >software should be installable, and ideally fully functional, >without systemd. > > 4. So failing to support non-systemd systems, where no such support is >available, is a bug. But it is *not* a release-critical bug. >Whether the requirement for systemd is recorded as a formal bug in >the Debian bug system, when no patches are available, is up to the >maintainer. > > 5. When a package has reduced functionality without systemd, this >should not generally be documented as a (direct or indirect) >Depends or Recommends on systemd-sysv. This is because with such >dependencies, installing such a package can attempt to switch the >init system, which is not the what the user wanted. For example, a >daemon with only a systemd unit file script should still be >installable on a non-systemd system, since it could be started >manually. > >One consequence of this is that on non-systemd systems it may be >possible to install software which will not work, or not work >properly, because of an undeclared dependency on systemd. This is >unfortunate but trying to switch the user's init system is worse. >We hope that better technical approaches can be developed to >address this. > > 6. We recognise that some maintainers find init scripts a burden and >we hope that the community is able to find ways to make it easier >to add support for non-default init systems. Discussions about the >design of such systems should be friendly and cooperative, and if >suitable arrangements are developed they should be supported in the >usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 7. Failing to support non-systemd systems when such support is >available, or offered in the form of patches (or packages), >*should* be treated as a release critical bug. For example: init >scripts *must not* be deleted merely because a systemd unit is >provided instead; patches which contribute support for other init >systems should be filed as bugs with severity `serious'. > >This is intended to provide a lightweight but effective path to >ensuring that reasonable support can be provided to Debian users, >even where the maintainer's priorities lie elsewhere. (Invoking >the Technical Committee about individual patches is not sensible.) > >If the patches are themselves RC-buggy (in the opinion of, >initially, the maintainer, and ultimately the Release Team) then of >course the bug report should be downgraded or closed. > > 8. Maintainers of systemd components, or other gatekeepers (including >other maintainers and the release team) sometimes 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 > > 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
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, Jul 07, 2016 at 03:37:08PM +0200, Nicolas Dandrimont wrote: > In 2005, the body of Debian Developers passed a General Resolution[1] > requiring the creation of a declassification team for the > debian-private mailing list. For the past ten years, the > implementation of this GR has never materialized, despite an explicit > call for volunteers[2] by the DPL in 2010. > > [1] https://www.debian.org/vote/2005/vote_002 > [2] https://lists.debian.org/debian-project/2010/05/msg00105.html > > Over the years, several important discussions have happened on the > debian-private mailing list that needed to stay private. Oftentimes, when a > discussion has carried on for a while, some participants have reminded others > that the discussion should be summarized in a public thread on either the > debian-devel or the debian-project mailing lists. > > While we agree with the intentions behind the original GR, we believe it is > now > time to acknowledge that the declassification of debian-private will never > happen, and that we should instead strongly encourage developers to move > discussions to public channels as soon as the sensitivity of the discussion > subsides. > > We therefore propose the following General Resolution: > > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === > > Thanks for your consideration, Seconded. J. -- signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 09:09:01AM +0200, Kurt Roeckx wrote: > On Thu, Apr 16, 2015 at 09:28:34PM -0500, Gunnar Wolf wrote: > > Kurt Roeckx dijo [Fri, Apr 17, 2015 at 12:45:37AM +0200]: > > > On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: > > > > > > > > Sadly this list is trivially proved inaccurate > > > > > > So I have no source at all that is can tell me the number of DDs? > > > > You can fetch the number of active DD keys [1,2], and add to it the > > number of removed 1024D keys [3]. When a person who had their key > > removed due to being too short presents a new key, we take the old one > > out of the removed-1024 tree as well. People with 1024D keys cannot > > vote, but don't lose their DD status. > > As far as I know relying on the keyring and ldap has always been > incorrect. The number was always off by a few. I've never quite understood why LDAP isn't accurate, but I couldn't figure out a simple query and even '(&(gidNumber=800)(!(shadowExpire=1))(objeass=debianDeveloper))' gives 988 entries of which some are incorrect. 3 of these have no key: adeodato, flatmax + schizo. flatmax has a lost key. adeodato + schizo are account renames and I'm not sure why the old ones are still around as active. 2 of those with fingerprints are keys that have been moved to emeritus but don't seem to have been cleaned up; they did not have RT tickets so I suspect they got missed and I have already filed an RT ticket for DSA to sort them out. 2 others of those with fingerprints are DDs with lost or revoked keys. The astute will notice that this leaves 981 keys, whereas I counted 983 keys in the keyrings. It turns out there are 2 DDs who have removed 1024 bit keys but who have locked LDAP accounts (issue with SSH key on one, "DSA locked" on the other as comments). Anyway. The 2 things to take away are a) yes, it's depressingly hard to work out how many voting members Debian has and b) the answer is 986 at present. > > Of course, the only authoritative number should be in the hands of > > DAM. But we have something, uh, quite close to it. > > It's was my understanding that DAM says that nm.debian.org is > authoritative. That is the eventual goal but at present various pieces of information are manually updated. Enrico and keyring-maint have been working on making it easier for nm.d.o to track keyring changes but there's still more to be done before this is complete. There's a vague plan to get this done during DebConf if not before. J. -- Revd Jonathan McDowell, ULC | Interesting concept. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 07:12:22PM +0200, Kurt Roeckx wrote: > On Thu, Apr 16, 2015 at 09:26:27AM +0100, Jonathan McDowell wrote: > > On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - > > Kurt Roeckx wrote: > > > > > Stats for the DPL votes: > > > |--+--++---++-++---| > > > | | Num || Valid | Unique | Rejects | % | Multiple | > > > | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | > > > |--+--++---++-++---| > > > | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | > > > |--+--++---++-++---| > > > > This num DDs seems a bit higher than I'd expect; it looks more like the > > number of DDs with active keys + emeritus DDs, rather than the number of > > DDs with active keys + number of non-uploading DDs with active keys + > > number of DDs with removed 1024 bit keys. > > > > active DD keys: 751 > > active DN keys: 12 > > 1024 bit removed DD keys: 220 > > emeritus keys: 283 > > > > So I think quorum is 983. It's possible the number might be one or two > > higher as that won't included anyone who is entirely missing a key at > > present but such situations are rare. > > I get the numbers from nm.debian.org, both at https://nm.debian.org/api > and https://nm.debian.org/public/findperson/ Sadly this list is trivially proved inaccurate; the list for Debian Developer, Uploading includes "stew" who was moved to emeritus back in January: https://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=b768c0a3506631ddeacf4c80ba8f3be6995e8a8f and "finger s...@db.debian.org" correctly returns no active fingerprint for the user. Copying Enrico who can no doubt comment more about the expected accuracy of nm.debian.org; AIUI it's still a work in progress in terms of being entirely up to date all the time. J. -- Don't just stand there, kill something. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 09:26:27AM +0100, Jonathan McDowell wrote: > On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - > Kurt Roeckx wrote: > > > Stats for the DPL votes: > > |--+--++---++-++---| > > | | Num || Valid | Unique | Rejects | % | Multiple | > > | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | > > |--+--++---++-++---| > > | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | > > |--+--++---++-++---| > > This num DDs seems a bit higher than I'd expect; it looks more like the > number of DDs with active keys + emeritus DDs, rather than the number of > DDs with active keys + number of non-uploading DDs with active keys + > number of DDs with removed 1024 bit keys. > > active DD keys: 751 > active DN keys:12 > 1024 bit removed DD keys: 220 > emeritus keys:283 > > So I think quorum is 983. It's possible the number might be one or two > higher as that won't included anyone who is entirely missing a key at > present but such situations are rare. As Phil has pointed out to me, I meant "total voters" here rather than "quorum". J. -- This .sig brought to you by the letter F and the number 26 Product of the Republic of HuggieTag signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - Kurt Roeckx wrote: > Stats for the DPL votes: > |--+--++---++-++---| > | | Num || Valid | Unique | Rejects | % | Multiple | > | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | > |--+--++---++-++---| > | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | > |--+--++---++-++---| This num DDs seems a bit higher than I'd expect; it looks more like the number of DDs with active keys + emeritus DDs, rather than the number of DDs with active keys + number of non-uploading DDs with active keys + number of DDs with removed 1024 bit keys. active DD keys: 751 active DN keys: 12 1024 bit removed DD keys: 220 emeritus keys: 283 So I think quorum is 983. It's possible the number might be one or two higher as that won't included anyone who is entirely missing a key at present but such situations are rare. J. -- The more things change the more | .''`. Debian GNU/Linux Developer things suck.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Question for Matthew Garrett (was Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > The following people in Debian leadership roles have also expressed their > support: > > Andreas Schuldei (DPL candidate) > Angus Lees (DPL candidate) > Branden Robinson (DPL candidate) > Jonathan Walther (DPL candidate) Matthew, would you like to elaborate on why you're the only DPL candidate not to have expressed some support for this plan? What are your objections to it? J. -- No bathroom? Just boldly go where no man has gone before! pgpQNCZgRGm10.pgp Description: PGP signature
