Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On Thu, Apr 11, 2024 at 11:48:18AM +0200, Christian Kastner wrote: > Hi Thomas, > > I overlooked this the first time, but > > On 2024-03-29 16:03, Thomas Goirand wrote: > > FYI, if I didn't go forward with the project, that we've been discussing > > with Jonathan over at least 3 years, is because I have no idea where to > > host it. I have clearly stated that having this hosted at *my* company > > (ie: Infomaniak) is *not* what I want to do to avoid any type of > > conflict of interest. I am staying firm with the idea that I shouldn't > > do that. > I understand your position morally but from a practical POV, speaking as > someone who's currently hosting servers in his living room, any hosting > option would be an improvement to me and one with by a Debian Project > Member even more so. > > And strictly speaking (1) I don't see a conflict of interest and (2) > even if there were one, these can be disclosed and dealt with. Hosting > isn't that opaque. > +1 -- Roberto C. Sánchez
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi Thomas, I overlooked this the first time, but On 2024-03-29 16:03, Thomas Goirand wrote: > FYI, if I didn't go forward with the project, that we've been discussing > with Jonathan over at least 3 years, is because I have no idea where to > host it. I have clearly stated that having this hosted at *my* company > (ie: Infomaniak) is *not* what I want to do to avoid any type of > conflict of interest. I am staying firm with the idea that I shouldn't > do that. I understand your position morally but from a practical POV, speaking as someone who's currently hosting servers in his living room, any hosting option would be an improvement to me and one with by a Debian Project Member even more so. And strictly speaking (1) I don't see a conflict of interest and (2) even if there were one, these can be disclosed and dealt with. Hosting isn't that opaque. Best, Christian
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On 2024/04/10 16:08, Felix Lechner wrote: On Wed, 27 Mar 2024 13:57:55 +0200, Jonathan Carter wrote: every single hardware request over the last 4 years (whether from DSA or from a DD) has been approved. Mine wasn't, although I probably didn't follow the proper procedure. I just wrote a private email to Jonathan. His response is below. I'm not going to re-hash what I previously said, it's all on record from the 2022 DPL election period: https://lists.debian.org/msgid-search/bdc81fe2-4490-a839-27b4-e610de369...@debian.org After which, you lost to NOTA and then rage quit Debian, and now, two years later, you're still bitter that you didn't get an SSD that you never bothered to file a request for. There comes a time where you need to know that it's time to let it go. -Jonathan
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi, On Wed, 27 Mar 2024 13:57:55 +0200, Jonathan Carter wrote: > every single hardware request over the last 4 years (whether from DSA > or from a DD) has been approved. Mine wasn't, although I probably didn't follow the proper procedure. I just wrote a private email to Jonathan. His response is below. Jonathan's reference to DAM was an interesting slip; I believe he meant DSA. I answered Jonathan's question from November 5, 2021, an hour later. I then sent a gentle reminder on February 3, 2022. Jonathan did not respond to either. After a public mention on this list [1] another seven weeks later, I eventually received a friendly message from a member of the treasurer team on April 5, 2022. The author "wonder[ed] if we can prepare an action plan somehow." The message further stated that "I hope Debian can reimburse you ASAP." None of the responses included the "pre-appoval" necessary according to step two in the documentation. [2] The point is now moot. Thanks! Kind regards Felix P.S. I do not subscribe to this mailing list. [1] https://lists.debian.org/debian-vote/2022/03/msg00212.html [2] https://wiki.debian.org/Teams/DPL/Reimbursement * * * Delivered-To: felix.lech...@gmail.com Received: by 2002:ac9:130d:0:0:0:0:0 with SMTP id d13csp659255occ; Fri, 5 Nov 2021 11:53:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyW0FjabyPnELL54pba39yRNCKzDObyZjunDs88YhG6F2Zw2bG5tSI3TsjDMy//OIoQFRdn X-Received: by 2002:a17:90a:312:: with SMTP id 18mr32421223pje.178.1636138383229; Fri, 05 Nov 2021 11:53:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636138383; cv=none; d=google.com; s=arc-20160816; b=IPHdRC1wI7E4UzbJfapk/b5DNTn1NoFN9CoVMIhiGLM7DVPdb2ZYm2NZn6oB3z3dFi 4YF5sAwgjkk4zQvK+JPrvj2bk48HlQR98qB2cjMQ0jONR+ELnjUovKcNijyxD6mduDQ+ +pJ9j0gRsv+d97MXo02wAUwtyUzBS1WK2K6zhArToSQOyX0WZQ1wMxRfCWZjor44cQZG BeJzHA0Oo+YQyR7qlxAYWEb3nHf+IxHPwsapZ5hgs+fAyZx6NPW9iqfHPxqjNj8Ymb4W s7Wj9oWr0eH5PE7Agk/AMoKRW8td3H3SSUuhMWtGWwQwh9t6QvSOzFOO2AjsIPGREahf krQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :dkim-signature:dkim-signature; bh=VTz2pGh3ePjzKg8f6nlMMQkZnVWZwR7w1LvBlybjmds=; b=jnjQy3kTDVAGaZsiwy6jt3tA0o6q7AVFrRAzbW4eY7HKuKTvbkYjvFO4AKeUVxZYyC 5/zcSgTfx19TUVoyKi9a8tzQpaWOOmvVEhf0hVBAGHvxBD8S5RbbMdc0hMiG/YI+ptjz g+VxTDIQGh3KW3eF8WX9FnJ1OVNxL++/Y/W75VoMT69hDPi+LiPzfpEKqDyr/fRXdquM ht2w3Xn6dpCYZyTL5fgk8PXWPSZoRM6vWTXTUf8WDiQYpXeatrPwiSrm4uY4F4mhrU2X u2qEyzXZ+Ls5DAeg6SiWJ1J0b4B3xQkx02xpIJbG8uwwNUi99JzgpksID9BgKnfsdLQa 8uVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@debian.org header.s=2017.lechner.user header.b=BoWnqNsl; dkim=neutral (no key) header.i=@debian.org header.s=2020.lechner.user; spf=neutral (google.com: 2a0b:ae40:2:4a0b::1 is neither permitted nor denied by best guess record for domain of j...@debian.org) smtp.mailfrom=j...@debian.org Return-Path: Received: from letbox-vps.us-core.com (letbox-vps.us-core.com. [2a0b:ae40:2:4a0b::1]) by mx.google.com with ESMTPS id c24si17776066pgn.435.2021.11.05.11.53.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Nov 2021 11:53:03 -0700 (PDT) Received-SPF: neutral (google.com: 2a0b:ae40:2:4a0b::1 is neither permitted nor denied by best guess record for domain of j...@debian.org) client-ip=2a0b:ae40:2:4a0b::1; Authentication-Results: mx.google.com; dkim=pass header.i=@debian.org header.s=2017.lechner.user header.b=BoWnqNsl; dkim=neutral (no key) header.i=@debian.org header.s=2020.lechner.user; spf=neutral (google.com: 2a0b:ae40:2:4a0b::1 is neither permitted nor denied by best guess record for domain of j...@debian.org) smtp.mailfrom=j...@debian.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=2017.lechner.user; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VTz2pGh3ePjzKg8f6nlMMQkZnVWZwR7w1LvBlybjmds=; b=BoWnqNsldUqNQwz7n03KOAxX8Y PjOWqYCO9R/zL+PML69G2OldGdqpo7DU7DIRO3xcUTlttA3CD9x0kn1vRt0zbmYMl9RRNfYPr/fDQ H8uF4kIcfmR5uNvs67ufnFZUJNn840qY1bR4lUd5zofaRI5AyFw/RYif7en8cG2JYtCE=; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=2020.lechner.user; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
Re: Question to all candidates: What are your technical goals
Hi, now that the campaign period has ended, I will write my longer answer on -devel where it belongs. On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber: > > I think this can't just be seen by looking at the statistiks. Many small > > packages do their job and don't need constant attention as long as they > > still build and work. > > I agree that pure statistics is not telling the whole story. However, > those statistics give some feeling about the issue which for sure needs > to be verified on case-by-case basis. I can assure you that I usually > inspect the list of smelly packages[1] whether there are hits for my > name (currently one false positive and one package where I'm forced to > use cdbs) but also look for packages I might be able to salvage from > there. I've found some impressive hits for this purpose in the past > that are supporting my point besides stupid statistics. > -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 10:14:59AM -0700 schrieb Soren Stoutner: > On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote: > >[ ] Its not acceptable, don't do that > >[ ] We should discuss this on debian-devel, possibly do some GR > >before things like this are permitted > >[ ] Wait one week before uploading > >[X] Wait one day before uploading > >[ ] Just upload provided you care for any break your action might > >have caused. > >[ ] ??? > > Given the circumstances, I think waiting one day before uploading is > appropriate. > > I also feel that asking this question on this list is appropriate. It is > insightful in helping me understand how Andreas would approach being the DPL, > thus informing my vote. Summarising my question about how to deal with an example RC bug that affects some dependency tree of some team: 1. Prefer NMU which solves the problem quickly. I do not volunteer to do this since I do not consider it sustainable in the said situation. 2. Prefer package salvaging (which I did now #1068561 but its a lengthy process that will trigger another series of testing removal warnings in between) 3. Two responses would agree to an alternative way which are not backed up by any procedure we agreed upon so I will not do this. I wonder whether we can use this as some input to simplify / shorten the salvage process or whether we should move on as before. Additional remark: When reading the PackageSalvaging FAQ[1] I realised that my way to talk about examples might be considered finger pointing no matter whether I write that this is not intended. I understand I was wrong here and I'm sorry about doing so. I do not intend to do this in future any more. Kind regards Andreas. [1] https://wiki.debian.org/PackageSalvaging#FAQs -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi again, Am Sat, Apr 06, 2024 at 09:26:25AM +0200 schrieb Tobias Frost: > > I want to be able to immediately respond to future problems in this > > package. I'm fine with putting Debian Med team as maintainer, but not > > my personal ID (maximum as Uploader since I do not have any personal > > packages). > > > > Do you think this would be the appropriate action (which I personally > > would even prefer over debian/ space)? The conservative criteria > > are fulfilled. > > Yes, (if your name is in Uploaders:) this is is fine. I've filed ITS bug #1068561. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Fri, Apr 05, 2024 at 12:37:19PM +0200, Andreas Tille wrote: > Hi Tobias, > > Am Thu, Apr 04, 2024 at 07:59:56PM +0200 schrieb Tobias Frost: > > > > There is the possilbity to salavage the packagei [1], but that of course > > will > > only work if the person agrees to take over maintainance and add their name > > to > > Uploaders: or Maintainer: [2]. > > I want to be able to immediately respond to future problems in this > package. I'm fine with putting Debian Med team as maintainer, but not > my personal ID (maximum as Uploader since I do not have any personal > packages). > > Do you think this would be the appropriate action (which I personally > would even prefer over debian/ space)? The conservative criteria > are fulfilled. Yes, (if your name is in Uploaders:) this is is fine. > Kind regards >Andreas. > > > The package can be put into a team's umbrella at the ITS time. This > > does not need an explicit OK, though the maintainer can veto. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > https://wiki.debian.org/PackageSalvaging > > > > [2] This is a feature, the ITS procedure has been designed exactly that > > way, to avoid that people just do an upload and drop the package > > immediatly afterwards, as this will likely only upset the current > > maintainer without long-term benefits to the package - kind of to > > avoid the reaction Marc predicted. > > If taking over the maintaince is not the goal, remember NMU allow > > one to fix almost every bug, also wishlist bugs are regularily in > > scope. And bugs can be filed, if needed. > > Some Background story: > > https://lists.debian.org/debian-devel/2018/07/msg00453.html > > > > -- > > tobi > > > > -- > https://fam-tille.de > signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Holger, Am Fri, Apr 05, 2024 at 10:42:35AM + schrieb Holger Levsen: > On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > > also: (NMU-)uploads to DELAYED/15 are great. > > Sorry, I do not feel my time well spent on just curing a symptom > > (unfixed RC bug) via NMU instead of addressing the underlying cause > > that the package is maintained by a single person. > > so you value your values and needs higher than our shared and agreed values. I do not think that we agreed upon how volunteers might spent their time. There is a patch in BTS for the said bug and I take the freedom to not NMU. At the time of writing it seems every other developer prefers to do other things than uploading the patch. No idea how you conclude from this fact to some values I'm weighting differently. What I want to find out is: Are the values we agreed upon meeting todays needs or not? Is the developer community interested in some change I might start or not? Please take this discussion as my way to find some pain points in the discussion to act more sensibly on debian-devel once we might talk about new ways. > noted. > > (also, pressuring people to accept more co-maintainers can have serious > side effects as became very visible last weekend with xz upstream...) Seems that case makes a great argument which is pretty popular these days. I'd love to have some explanation in how far it matches the example I gave. I have no means to pressure anybody - neither to make a maintainer accept contributions nor any co-maintainer to provide any contribution. My point is to enable better chances for cooperation between people we trust anyway. > Make facts great again. Yeah! Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: GDPR compliance review
> "Adrian" == Adrian Bunk writes: Adrian> If I send an email requesting all data Debian has about me to Adrian> data-protect...@debian.org, will I receive a complete reply within the Adrian> expected time, including all data members of delegations like the Adrian> Debian Account Managers and the Community Team might have? Someone did exactly that while I was DPL. They received a response within the GPR's allowed time giving them all data Debian held regarding them that was not covered by an exception to the GDPR. They also received a list of exceptions to the GDPR that might apply to data that was not turned over. This was all handled in a manner consistent with the advice received from a lawyer specializing in GDPR issues that was ultimately paid for by SPI. As you might imagine, there are GDPR exceptions that apply to some classes of data that DAM routinely processes. I cannot speak to the community team as the community team did not exist at the time of this request. --Sam
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 05, 2024 at 04:38:57PM +0200, Andreas Tille wrote: > Hi Adrian, Hi Andreas, > Am Fri, Apr 05, 2024 at 12:41:17AM +0300 schrieb Adrian Bunk: >... > > Many parts of Debians Privacy Policy look questionable. > > > > For example the rights are not stated, and in addition to this being a > > formal problem there is also the question whether for example the Debian > > Data Protection team does fulfil the right to request only where > > required by law or whether all people around the world are treated > > the same. > > I need to admit I do not understand this example. the Privacy Policy lacks explicit statements of the rights like You have the right to request a copy of all personal data. that are legally required. An explicit statement would also make it clear whether or not Debian might extend such rights to people not covered by the GDPR. > > The attempts in the Privacy Policy for blanket eternal storage > > of data might not pass a legal review, especially when this might > > contain sensitive data like sexual orientation or political opinions. > > I'm not aware that those personal data are stored. If this is really > the case you have a point. During the RMS GR I was often thinking "assume RMS was living in the EU". The archives of debian-vote contain plenty of sensitive data like political opinions of RMS where it is questionable that they could be stored forever if the GDPR applied. And who in Debian would have been responsible of informing him that sensitive personal data about him is being stored by Debian that was provided by third parties? >... > > I would be glad to hear from a qualified person that I am wrong and that > > all handling of personal data by these teams is lawful. > > If I understand you correctly you want to know my opinion whether Debian > should pay some lawyer specialized in data privacy to inspect "all > handling of personal data", right? Yes. > > There is also a personal side for me: > > > > I am feeling quite unsafe in Debian due to not knowing what data people > > in positions of power in Debian who dislike me might have about me, and > > I want to request all data about me in Debian. This is also a prerequisite > > for exercising the right of rectification of inaccurate personal data if > > any data turns out to be incorrect. > > While I may be somewhat naive, I'm unaware of any positions within > Debian that hold the power to harm others. IMHO, the most troubling > aspect is your feeling that there are individuals who dislike you. If > you really feel unsafe about this situation IMHO the first step should > be to talk to some individual you are trusting inside Debian. >... If I send an email requesting all data Debian has about me to data-protect...@debian.org, will I receive a complete reply within the expected time, including all data members of delegations like the Debian Account Managers and the Community Team might have? > Kind regards > Andreas. >... cu Adrian
Re: Question to all candidates: Bits from the DPL?
On 03/04/24 01:35, Louis-Philippe Véronneau wrote: Hello! Jonathan's latest "Bits from the DPL" entry reminded me of how much I like those :) I also like reading them. What are your thoughts on the format? I like the format, but sometimes it becomes too long that I end up not finishing reading them in one go. If you are elected, do you plan to publish regular "Bits"? If not, how do you plan to communicate with the rest of the project with regards to the work you are doing? Yes, I do plan to have regular "Bits" and may be increase the frequency so that the mails are not too long. Apart from the "Bits" mail, I intend to communicate to the project about all the important decisions/topics. Cheers! OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to all candidates: GDPR compliance review
On 05/04/24 03:11, Adrian Bunk wrote: Hi, this email has two parts: A short question where I would appreciate a "yes" or "no" answer from all candidates, and a longer explanation what and why I am asking. Question: If elected, will you commit to have a lawyer specialized in that area review policies and practices around handling of personal data in Debian for GDPR compliance, and report the result of the review to all project members by the end of 2024? Maybe. I do think we might need some review in this regard, but right now I do not have all the details about GDPR, so I can't be sure and say yes. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to all candidates: What are your technical goals
On 03/04/24 01:42, Marc Haber wrote: Dear Candidates, There are many people who see Debian as a technology project, with the technical goal of producing The Universal Operating System. I believe that Debian is both a technology project and a community. What are you planning to do to Debian from a technical and technological point of view? What do we well, where do we suck on the technical site? If we do suck in some technical points, what are you planning to do to improve those things? I believe position of DPL is more of an administrative position than a technical decision making position. If I become the DPL, I would love to hear answers for the above questions from the whole project and let us all, as a project, come up with some great solutions. What is your position about technical leadership? Are our technical decision-making processes up to today's challenges? In Debian, I do not think we need a technical leadership through a DPL. I consider this as the unique aspect of our Constitution that sets Debian apart from other distros. In Debian, unlike other distros, every Debian Member can start and lead the change they want in Debian. Let us take the example of non-free firmware in Debian. It was one of the biggest technical change in Debian, but the DPL was not the one who lead the discussions/decision-making process. I believe the decision making system in Debian is good enough that DPL need not be involved in technical decision making. Thanks for your consideration to answer these questions despite platforms containing language about this topic. Greetings Marc OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Scott, Am Thu, Apr 04, 2024 at 01:12:45PM + schrieb Scott Kitterman: > On April 4, 2024 12:59:34 PM UTC, Andreas Tille wrote: > >I would like to learn what options I have to realise paragraph > > > > Packaging standards > > > >of my platform. > > Obviously the DPL has an outsized voice in Debian. When the DPL says > something, it will tend to get more attention within the project. I agree with "more attention" but I doubt attention is some specific power. > Beyond that, what specific powers of the DPL will help you realize this goal? > In other words, why do you need to be DPL to do this? Quoting myself: I consider the DPL as a "Leader with no power" so no specific powers. I'd possibly like to profit from the higher level of attention that might motivate others to join the discussion. Thus I might have a better chance to moderate this discussion (but I might be wrong here). Private reason: I will be motivated to dedicate time into this process which I have spent all the years more on packaging and QA work. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: GDPR compliance review
Hi Adrian, Am Fri, Apr 05, 2024 at 12:41:17AM +0300 schrieb Adrian Bunk: > this email has two parts: > A short question where I would appreciate a "yes" or "no" answer from > all candidates, and a longer explanation what and why I am asking. > > > Question: > > If elected, will you commit to have a lawyer specialized in that area > review policies and practices around handling of personal data in Debian > for GDPR compliance, and report the result of the review to all project > members by the end of 2024? No. > Explanation: Explanation for my "No". You wanted a binary answer and you got it. I doubt a binary answer to a complex question that needs a long explanation is appropriate. > One might discuss whether or not Debian should aim at being better than > average in the area of privacy, but compliance with the law is the > minimum everyone can expect. > > Unlawful actions can have consequences, organizations and > individuals might be subject to fines up to 20 Million Euro > as well as compensation for material and non-material damage, > and in some countries also prosecution under criminal law. > > > Many parts of Debians Privacy Policy look questionable. > > For example the rights are not stated, and in addition to this being a > formal problem there is also the question whether for example the Debian > Data Protection team does fulfil the right to request only where > required by law or whether all people around the world are treated > the same. I need to admit I do not understand this example. > The attempts in the Privacy Policy for blanket eternal storage > of data might not pass a legal review, especially when this might > contain sensitive data like sexual orientation or political opinions. I'm not aware that those personal data are stored. If this is really the case you have a point. > I also suspect that the Debian Account Manager and Community Teams > might be abusing people by illegally processing data outside of what > is being permitted by the Privacy Policy. I've reviewed the "State of the Data Protection team" talk from DebConf22[1]. I understand that you can address those suspicions with this team. > I would be glad to hear from a qualified person that I am wrong and that > all handling of personal data by these teams is lawful. If I understand you correctly you want to know my opinion whether Debian should pay some lawyer specialized in data privacy to inspect "all handling of personal data", right? > There is also a personal side for me: > > I am feeling quite unsafe in Debian due to not knowing what data people > in positions of power in Debian who dislike me might have about me, and > I want to request all data about me in Debian. This is also a prerequisite > for exercising the right of rectification of inaccurate personal data if > any data turns out to be incorrect. While I may be somewhat naive, I'm unaware of any positions within Debian that hold the power to harm others. IMHO, the most troubling aspect is your feeling that there are individuals who dislike you. If you really feel unsafe about this situation IMHO the first step should be to talk to some individual you are trusting inside Debian. > I would wish that Debian itself can ensure that all handling of personal > data is lawful, and that GDPR requests are being fulfilled without > problems - like everywhere else. I'm not particularly well-versed in GDPR issues, but I would imagine that there must be a justified suspicion before seeking legal counsel. > Other places with DDs also have laws protecting personal data > (at least California, China, Brazil, South Africa, Singapore). > > I am asking specifically about GDPR since that affects me directly, but > either during the GDPR review or afterwards it would of course be good > to also obtain legal advice whether there are additional requirements > in other jurisdictions. To qualify my previously stated 'no' I'd rather say: No, except you come up with some more specific example (feel free to do this in private and if you like in our common mother language). Alternatively, the urgency of the issue might be highlighted by several other developers to bring my attention to the severity of the problem. Kind regards Andreas. [1] https://debconf22.debconf.org/talks/39-state-of-the-data-protection-team/ -- https://fam-tille.de
Re: Question to all candidates: What are your technical goals
On Fri, 5 Apr 2024 at 11:18, Andreas Tille wrote: > > Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi: > > > Please don't get me wrong: I do not consider Fedora a commercial > > > entity. I simply subscribe the statement that we are facing some > > > problems in Debian since we are not a commercial entity. > > > > I think the framing is slightly misleading: it's true that a > > commercial entity with a hierarchical structure would not have the > > same issue, but the point I am making is that there's nothing stopping > > a non-commercial entity from having a structure that allows the same > > decision-making and executing, as proved by Fedora. > > Well, do you think well-respected members of our community who disagree > with a change of structure are "nothing"? In preparation of my platform > I started kind of a test ballon inside DPT where I spotted something I > considered wrong inside the team policy and suggested a change[1]. > There were a lot of positive responses and finally the change was > accepted. But even before this happened we've lost two major > contributors[2] (leaving more or less silently) and [3]. I confirm I > made mistakes in this process and hopefully learned from it. > > So we have to deal with people and changing a structure that has evolved > over >30 years might be harder than in the case of other distributions > with a different history. IMHO changing a structure is harder than > creating one from scratch. That is answered in the bit you quoted below: > _plus_ precise and explicit choices about project governance Project governance is a choice, there's no law of physics that says it has to be done one way or the other, even outside of a commercial setting. Yes, it is harder to change than to start from scratch, there's no doubt about it. > > Hence, it's not > > just the fact that Debian is not a commercial entity that leads to the > > status quo, but the combination of not being a commercial entity > > _plus_ precise and explicit choices about project governance. > > I'm kindly inviting everybody to join me in drafting a GR about this (no > matter whether I might get elected or not). Happy to help > > > If you compare this to Debian what exactly is your proposal to change > > > for the better? > > > > For starters there needs to be a decision on whether the status quo is > > fine or change is needed. That is non-obvious, I have my opinion but > > others will have theirs. It would mean the end of "my package is my > > fiefdom", and a move towards collective maintenance. > > I share this opinion 100%. > > > From the organizational point of view, it would require a GR to change > > in the constitution to enshrine the power to take technical decisions > > and make them happen into a constitutional body - the CTTE will > > probably say "no no no not us, please, no", but I'm pretty sure that's > > exactly where such power should reside, especially because they don't > > want it. > > I fail to see the logic in this "especially because they don't want it" > but I agree that I see the potential decision making body in the CTTE. > To say it clearly: It should by no means be DPL (and I hope your logic > does not apply to this statement as well. ;-P ) There's an old maxim about the people best suited to hold power being those who want it the least or not at all, it was a quip made in that general direction, no special meaning. > > A procedure to submit proposals for discussion with the whole > > project should be established (we already have the DEP process for > > example), that ends with a vote of the decision makers body. And once > > the body makes a technical strategy decision, them or whoever they > > want to empower, can go and make it happen, without having to walk on > > eggshells and dance around sacred cows - the time to dissent and > > discuss is _before_ the decision is made, not _after_. > > To stick to one example I gave in an other thread on this list: Assuming > we decided to move all packages on Salsa, I could start importing > packages that are not on Salsa and upload these starting from the day > after this decision without asking the maintainer? Being empowered to execute a decision doesn't discount common courtesy, so maintainers would be kept in the loop, but essentially yes, that would be one example > > In Fedora every > > proposal must include a criteria to allow declaring that the game's a > > bogey and plan to rollback, in case something goes wrong, but this is > > again decided by the decision makers body. > > Interesting detail which is probably not feasible for every decision > (since its hard to imagine how to roll back a "move all packages on > Salsa" decision). In that case it would probably be something along the lines of "it is no longer mandatory"
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > also: (NMU-)uploads to DELAYED/15 are great. > Sorry, I do not feel my time well spent on just curing a symptom > (unfixed RC bug) via NMU instead of addressing the underlying cause > that the package is maintained by a single person. so you value your values and needs higher than our shared and agreed values. noted. (also, pressuring people to accept more co-maintainers can have serious side effects as became very visible last weekend with xz upstream...) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Tobias, Am Thu, Apr 04, 2024 at 07:59:56PM +0200 schrieb Tobias Frost: > > There is the possilbity to salavage the packagei [1], but that of course will > only work if the person agrees to take over maintainance and add their name to > Uploaders: or Maintainer: [2]. I want to be able to immediately respond to future problems in this package. I'm fine with putting Debian Med team as maintainer, but not my personal ID (maximum as Uploader since I do not have any personal packages). Do you think this would be the appropriate action (which I personally would even prefer over debian/ space)? The conservative criteria are fulfilled. Kind regards Andreas. > The package can be put into a team's umbrella at the ITS time. This > does not need an explicit OK, though the maintainer can veto. > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > https://wiki.debian.org/PackageSalvaging > > [2] This is a feature, the ITS procedure has been designed exactly that > way, to avoid that people just do an upload and drop the package > immediatly afterwards, as this will likely only upset the current > maintainer without long-term benefits to the package - kind of to > avoid the reaction Marc predicted. > If taking over the maintaince is not the goal, remember NMU allow > one to fix almost every bug, also wishlist bugs are regularily in > scope. And bugs can be filed, if needed. > Some Background story: > https://lists.debian.org/debian-devel/2018/07/msg00453.html > > -- > tobi -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Fri, Apr 05, 2024 at 09:55:56AM + schrieb Holger Levsen: > On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > > [...] I could follow the normal NMU procedure but I do not consider > > this a sustainable solution. > [...] > > I did not uploaded my work but I would like to know what action is > > considered acceptable by the voters. I repeat that the package is no > > key package for which I would not consider what I did above. Please > > simply fill in the form: > > > >[ ] Its not acceptable, don't do that > >[ ] We should discuss this on debian-devel, possibly do some GR > >before things like this are permitted > >[ ] Wait one week before uploading > >[ ] Wait one day before uploading > >[ ] Just upload provided you care for any break your action might > >have caused. > >[ ] ??? > > > > What do you think? > > rereading this, I must say I think "wtf". > > please *do* follow the NMU procedures or salvage the package. (or leave it > alone.) Salvaging would mean to set a new maintainer. I could make the Debian Med team new maintainer since we are obviously affected and we are packaging several preconditions. Do you consider this better than debian/ space? > also: (NMU-)uploads to DELAYED/15 are great. Sorry, I do not feel my time well spent on just curing a symptom (unfixed RC bug) via NMU instead of addressing the underlying cause that the package is maintained by a single person. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: What are your technical goals
Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi: > > Please don't get me wrong: I do not consider Fedora a commercial > > entity. I simply subscribe the statement that we are facing some > > problems in Debian since we are not a commercial entity. > > I think the framing is slightly misleading: it's true that a > commercial entity with a hierarchical structure would not have the > same issue, but the point I am making is that there's nothing stopping > a non-commercial entity from having a structure that allows the same > decision-making and executing, as proved by Fedora. Well, do you think well-respected members of our community who disagree with a change of structure are "nothing"? In preparation of my platform I started kind of a test ballon inside DPT where I spotted something I considered wrong inside the team policy and suggested a change[1]. There were a lot of positive responses and finally the change was accepted. But even before this happened we've lost two major contributors[2] (leaving more or less silently) and [3]. I confirm I made mistakes in this process and hopefully learned from it. So we have to deal with people and changing a structure that has evolved over >30 years might be harder than in the case of other distributions with a different history. IMHO changing a structure is harder than creating one from scratch. > Hence, it's not > just the fact that Debian is not a commercial entity that leads to the > status quo, but the combination of not being a commercial entity > _plus_ precise and explicit choices about project governance. I'm kindly inviting everybody to join me in drafting a GR about this (no matter whether I might get elected or not). > > If you compare this to Debian what exactly is your proposal to change > > for the better? > > For starters there needs to be a decision on whether the status quo is > fine or change is needed. That is non-obvious, I have my opinion but > others will have theirs. It would mean the end of "my package is my > fiefdom", and a move towards collective maintenance. I share this opinion 100%. > From the organizational point of view, it would require a GR to change > in the constitution to enshrine the power to take technical decisions > and make them happen into a constitutional body - the CTTE will > probably say "no no no not us, please, no", but I'm pretty sure that's > exactly where such power should reside, especially because they don't > want it. I fail to see the logic in this "especially because they don't want it" but I agree that I see the potential decision making body in the CTTE. To say it clearly: It should by no means be DPL (and I hope your logic does not apply to this statement as well. ;-P ) > A procedure to submit proposals for discussion with the whole > project should be established (we already have the DEP process for > example), that ends with a vote of the decision makers body. And once > the body makes a technical strategy decision, them or whoever they > want to empower, can go and make it happen, without having to walk on > eggshells and dance around sacred cows - the time to dissent and > discuss is _before_ the decision is made, not _after_. To stick to one example I gave in an other thread on this list: Assuming we decided to move all packages on Salsa, I could start importing packages that are not on Salsa and upload these starting from the day after this decision without asking the maintainer? > In Fedora every > proposal must include a criteria to allow declaring that the game's a > bogey and plan to rollback, in case something goes wrong, but this is > again decided by the decision makers body. Interesting detail which is probably not feasible for every decision (since its hard to imagine how to roll back a "move all packages on Salsa" decision). > In practical terms, it would probably be made easier if it was > mandatory for all packages to be on Salsa, either in the 'debian' > namespace or in a team namespace (but not under individual users). ACK > Then perhaps for each approved decision, until the project is > completed the implementer(s) would automatically get write access to > all teams namespaces to push the changes - as MRs because reviews are > good, but with the powers to merge them too. Sounds sensible. > I'm getting ahead of myself, but hopefully you get the idea. I perfectly get the idea since I basically subscribe this for years. Kind regards Andreas. [1] https://lists.debian.org/debian-python/2024/02/msg00052.html [2] https://lists.debian.org/debian-python/2024/03/msg00043.html [3] https://lists.debian.org/debian-python/2024/03/msg00118.html -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > [...] I could follow the normal NMU procedure but I do not consider > this a sustainable solution. [...] > I did not uploaded my work but I would like to know what action is > considered acceptable by the voters. I repeat that the package is no > key package for which I would not consider what I did above. Please > simply fill in the form: > >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[ ] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? > > What do you think? rereading this, I must say I think "wtf". please *do* follow the NMU procedures or salvage the package. (or leave it alone.) also: (NMU-)uploads to DELAYED/15 are great. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Everyone is entitled to their own opinion, but not their own facts. signature.asc Description: PGP signature
Re: Question to all candidates: What are your technical goals
Hi, Am Thu, Apr 04, 2024 at 09:55:33PM +0100 schrieb Luca Boccassi: > On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli wrote: > > > > > In practical terms, it would probably be made easier if it was > > > mandatory for all packages to be on Salsa, either in the 'debian' > > > namespace or in a team namespace (but not under individual users). > > > > Realistically, even if you decide "everything is now team maintained", if > > there is only 1 person who cares about a certain package there won't be any > > team member doing anything about it. This is perfectly true and I've seen quite a lot of team maintained packages that are effectively touched by one team member only. You might like to compare the graphs of maintainer per package of Pkg Perl team[1] where the majority of packages is maintained by 4-6 people, DPT [2] where the majority of packages is maintained by 2-4 people and Debian Science team[3] where we have de facto a single maintainership per the majority of packages. The differences are divers and need extra discussion. Specifically you can't compare specialised scientific software with general language packages used in many dependencies. However, I tend to think that the difference between Pkg Perl and DPT are partly caused by the culture inside the team. In three teams I was involved we basically forked Pkg Perl policy which was wide open to team wide changes. In contrast to this the DPT policy had some de-facto non-team option and it caused some friction (to say it extremely short) to drop this[4]. What I want to say is: The pure *option* to have more than one person touching a package makes quite a difference. For sure its no guarantie that this will happen. (And I'm really curious what will happen in Pkg R team if I might stop my work there for one year[5]. > > So having it on salsa or whatever won't > > really do much, besides being annoying for people who have to change their > > workflow for no reason. > > Sure, but this is in the context of project-wide changes discussed above. This argument is even stronger innfavour of team maintenance. Beeing asked about technical lead here: We are possibly lagging even more in maintenance way behind other organisations. Using Git should be default these days. Changing the workflow to point to Salsa instead to somewhere else should be not that dramatically annoying for everybody given there are good reasons to do so. > > Also let's not forget that it is expected for people who are not DD to > > contribute to debian, and they can only create repositories on salsa under > > their own name (for good reason, mostly). > > Such contributors need a DD sponsor, which means access can be granted > to individual repositories. ACK. Kind regards Andreas. [1] http://blends.debian.net/liststats/maintainer_per_package_pkg-perl.png [2] http://blends.debian.net/liststats/maintainer_per_package_python-team.png [3] http://blends.debian.net/liststats/maintainer_per_package_debian-science.png [4] https://lists.debian.org/debian-python/2024/02/msg00052.html [5] https://lists.debian.org/debian-r/2024/03/msg0.html -- https://fam-tille.de
Question to all candidates: GDPR compliance review
Hi, this email has two parts: A short question where I would appreciate a "yes" or "no" answer from all candidates, and a longer explanation what and why I am asking. Question: If elected, will you commit to have a lawyer specialized in that area review policies and practices around handling of personal data in Debian for GDPR compliance, and report the result of the review to all project members by the end of 2024? Explanation: One might discuss whether or not Debian should aim at being better than average in the area of privacy, but compliance with the law is the minimum everyone can expect. Unlawful actions can have consequences, organizations and individuals might be subject to fines up to 20 Million Euro as well as compensation for material and non-material damage, and in some countries also prosecution under criminal law. Many parts of Debians Privacy Policy look questionable. For example the rights are not stated, and in addition to this being a formal problem there is also the question whether for example the Debian Data Protection team does fulfil the right to request only where required by law or whether all people around the world are treated the same. The attempts in the Privacy Policy for blanket eternal storage of data might not pass a legal review, especially when this might contain sensitive data like sexual orientation or political opinions. I also suspect that the Debian Account Manager and Community Teams might be abusing people by illegally processing data outside of what is being permitted by the Privacy Policy. I would be glad to hear from a qualified person that I am wrong and that all handling of personal data by these teams is lawful. There is also a personal side for me: I am feeling quite unsafe in Debian due to not knowing what data people in positions of power in Debian who dislike me might have about me, and I want to request all data about me in Debian. This is also a prerequisite for exercising the right of rectification of inaccurate personal data if any data turns out to be incorrect. I would wish that Debian itself can ensure that all handling of personal data is lawful, and that GDPR requests are being fulfilled without problems - like everywhere else. Other places with DDs also have laws protecting personal data (at least California, China, Brazil, South Africa, Singapore). I am asking specifically about GDPR since that affects me directly, but either during the GDPR review or afterwards it would of course be good to also obtain legal advice whether there are additional requirements in other jurisdictions. Thanks Adrian
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli wrote: > > > In practical terms, it would probably be made easier if it was > > mandatory for all packages to be on Salsa, either in the 'debian' > > namespace or in a team namespace (but not under individual users). > > Realistically, even if you decide "everything is now team maintained", if > there is only 1 person who cares about a certain package there won't be any > team member doing anything about it. So having it on salsa or whatever won't > really do much, besides being annoying for people who have to change their > workflow for no reason. Sure, but this is in the context of project-wide changes discussed above. > Also let's not forget that it is expected for people who are not DD to > contribute to debian, and they can only create repositories on salsa under > their own name (for good reason, mostly). Such contributors need a DD sponsor, which means access can be granted to individual repositories.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Andreas, On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > Hi, > > in the light of the previous discussion I have a question to all voters. > Due to bug #1066377 more than 30 testing removal warnings hit my mailbox > today (I stopped counting after 30). While the Debian Med package > clustalo is the only package that's responsible for this due to its > Build-Dependency from libargtable2-dev there is quite some dependency > tree inside Debian Med team also affecting packages relevant for > COVID-19 etc. This small lib is not a key package which is important > for all things I'm writing below. Its used as Build-Depends by 6 other > packages. > > Our always busy team member Étienne Mollier provided a patch 10 days ago > (thanks again Étienne). The package had its last maintainer Upload > > -- Shachar Shemesh Sat, 16 Jul 2016 20:45:15 +0300 > > (Shachar in CC) and a NMU > > -- Holger Levsen Fri, 01 Jan 2021 17:15:04 +0100 > > (reproducible build, no changes - in other words no problems since > 2016). However, the BTS view of Sanchar might hinting for some > inactivity when looking at two RC bugs in other packages: > > #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm > #998987 [src:privbind] privbind: missing required debian/rules targets > build-arch and/or build-indep > > As I wrote to Marc here on this list also the explicit hint to Shachar: > Its not about blaming you - I just want to analyse the current situation > to act properly. Given that you had no capacity to respond to two bugs > that are RC since 2 years makes me wonder how long I need to wait for > your OK to a team upload I'm proposing below. I'm perfectly aware that > we as volunteers can't be blamed about those things. I simply want to > find new ways how to deal with those situations appropriately. There is the possilbity to salavage the packagei [1], but that of course will only work if the person agrees to take over maintainance and add their name to Uploaders: or Maintainer: [2]. The package can be put into a team's umbrella at the ITS time. This does not need an explicit OK, though the maintainer can veto. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging https://wiki.debian.org/PackageSalvaging [2] This is a feature, the ITS procedure has been designed exactly that way, to avoid that people just do an upload and drop the package immediatly afterwards, as this will likely only upset the current maintainer without long-term benefits to the package - kind of to avoid the reaction Marc predicted. If taking over the maintaince is not the goal, remember NMU allow one to fix almost every bug, also wishlist bugs are regularily in scope. And bugs can be filed, if needed. Some Background story: https://lists.debian.org/debian-devel/2018/07/msg00453.html -- tobi signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote: >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[X] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? Given the circumstances, I think waiting one day before uploading is appropriate. I also feel that asking this question on this list is appropriate. It is insightful in helping me understand how Andreas would approach being the DPL, thus informing my vote. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 01:04:49PM + schrieb Holger Levsen: > On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > > I would like to learn what options I have to realise paragraph > >Packaging standards > > of my platform. > > I also think this feels a bit like abusing the election audience for a > topic Fair enough. I personally have seen the campaigning period as a way voters might learn how I intend to work. You can take my message also as my style of leadership to ask in advance to get some picture. > which should be discussed on -devel outside campaigning. I confirm debian-devel is the right place to discuss this issue in detail and for sure I would move (or better reopen) the discussion there. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[X] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? For a younger RC bug, use a longer waiting period. But here things are clear that nothing would happen in a week. And, of course, anyway, care for any break you have caused. As a maintainer, seeing my package break after an NMU, I would sit tight and silent for a few days and wait for the NMUer to fix their damage. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 13:40, Andreas Tille wrote: > > Hi Luca, > > Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > > > That's the price we currently pay for being not a commercial entity, > > > > > > I fully subscribe to this statement. > > > > I don't think commercial entities have anything to do with this. > > Fedora is not a commercial entity (please, no FUD about RH) and yet it > > can take decisions and implement them just fine. It's entirely a > > question of self-organization and what rules we decide for the > > project. > > Please don't get me wrong: I do not consider Fedora a commercial > entity. I simply subscribe the statement that we are facing some > problems in Debian since we are not a commercial entity. I think the framing is slightly misleading: it's true that a commercial entity with a hierarchical structure would not have the same issue, but the point I am making is that there's nothing stopping a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora. Hence, it's not just the fact that Debian is not a commercial entity that leads to the status quo, but the combination of not being a commercial entity _plus_ precise and explicit choices about project governance. > > > I need to admit that I (currently) don't know much about Fedora (but I > > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > > took the chance to talk to OpenSUSE and Nix about organisatorical > > > solutions. There was no booth by Fedora I could show up. > > > > In short, Fedora project members elect a technical committee, FESCO. > > Project members can submit proposals to this committee for > > project-wide changes, which votes on whether to approve them or reject > > them. If they are approved, the committee and the proposer are > > empowered to enact the changes distro-wide - whether individual > > package maintainers like them or not. An approved proposal can fail > > and be rolled back for technical reasons (e.g.: unexpected issues crop > > up at implementation time), but not because random package maintainers > > practice obstructionism because they don't like the decision. > > If you compare this to Debian what exactly is your proposal to change > for the better? For starters there needs to be a decision on whether the status quo is fine or change is needed. That is non-obvious, I have my opinion but others will have theirs. It would mean the end of "my package is my fiefdom", and a move towards collective maintenance. >From the organizational point of view, it would require a GR to change in the constitution to enshrine the power to take technical decisions and make them happen into a constitutional body - the CTTE will probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't want it. A procedure to submit proposals for discussion with the whole project should be established (we already have the DEP process for example), that ends with a vote of the decision makers body. And once the body makes a technical strategy decision, them or whoever they want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and discuss is _before_ the decision is made, not _after_. In Fedora every proposal must include a criteria to allow declaring that the game's a bogey and plan to rollback, in case something goes wrong, but this is again decided by the decision makers body. In practical terms, it would probably be made easier if it was mandatory for all packages to be on Salsa, either in the 'debian' namespace or in a team namespace (but not under individual users). Then perhaps for each approved decision, until the project is completed the implementer(s) would automatically get write access to all teams namespaces to push the changes - as MRs because reviews are good, but with the powers to merge them too. I'm getting ahead of myself, but hopefully you get the idea.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On April 4, 2024 12:59:34 PM UTC, Andreas Tille wrote: >Hi Scott, > >Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman: >> I'm interested to understand what you think this has to do with the DPL >> election or the role of the DPL within the project? > >I would like to learn what options I have to realise paragraph > > Packaging standards > >of my platform. Thanks. Obviously the DPL has an outsized voice in Debian. When the DPL says something, it will tend to get more attention within the project. Beyond that, what specific powers of the DPL will help you realize this goal? In other words, why do you need to be DPL to do this? Scott K
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > I would like to learn what options I have to realise paragraph >Packaging standards > of my platform. I also think this feels a bit like abusing the election audience for a topic which should be discussed on -devel outside campaigning. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Scott, Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman: > I'm interested to understand what you think this has to do with the DPL > election or the role of the DPL within the project? I would like to learn what options I have to realise paragraph Packaging standards of my platform. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On April 4, 2024 12:32:45 PM UTC, Andreas Tille wrote: >Hi, > >in the light of the previous discussion I have a question to all voters. >Due to bug #1066377 more than 30 testing removal warnings hit my mailbox >today (I stopped counting after 30). While the Debian Med package >clustalo is the only package that's responsible for this due to its >Build-Dependency from libargtable2-dev there is quite some dependency >tree inside Debian Med team also affecting packages relevant for >COVID-19 etc. This small lib is not a key package which is important >for all things I'm writing below. Its used as Build-Depends by 6 other >packages. ... > >What do you think? > Andreas, I'm interested to understand what you think this has to do with the DPL election or the role of the DPL within the project? Scott K
Re: Question to all candidates: What are your technical goals
Hi Luca, Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > As far as I know other major distributions do not undertake the time_t > > 64bit transition (whether this marks leadership or not is questionable > > but it will make us the leading distribution on those architectures in > > future). > > Of course they are, most of the important work lately has been done by > SUSE for example, to replace legacy components that will hopelessly > break in 2038. Of course they have an advantage in not having to carry > around dead architectures, so it's easier. Thank you for the information. > > I think we are doing a good job regarding CI with adding autopkgtests > > (but we could do even better for sure). I'm not informed about the > > status of CI in other distributions and whether there exists something > > like Salsa CI. I'm positively convinced that Debian has reached a level > > of complexity which makes CI tests mandatory for every important package > > and I would love if we could do the lead here. > > OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's > source control system has a CI integrated with it that is similar to > the one we have. Packit is even starting to make its way in upstream > projects's CIs, we use it in systemd for example, so that upstream PRs > also build and test Fedora packages in Fedora images. We do the same > with Debian and autopkgtest btw. Thanks again. As I admitted in my platform I'm not well informed about other distributions but I'm willing to become better informed to be able to learn from others. > > > That's the price we currently pay for being not a commercial entity, > > > > I fully subscribe to this statement. > > I don't think commercial entities have anything to do with this. > Fedora is not a commercial entity (please, no FUD about RH) and yet it > can take decisions and implement them just fine. It's entirely a > question of self-organization and what rules we decide for the > project. Please don't get me wrong: I do not consider Fedora a commercial entity. I simply subscribe the statement that we are facing some problems in Debian since we are not a commercial entity. > > I need to admit that I (currently) don't know much about Fedora (but I > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > took the chance to talk to OpenSUSE and Nix about organisatorical > > solutions. There was no booth by Fedora I could show up. > > In short, Fedora project members elect a technical committee, FESCO. > Project members can submit proposals to this committee for > project-wide changes, which votes on whether to approve them or reject > them. If they are approved, the committee and the proposer are > empowered to enact the changes distro-wide - whether individual > package maintainers like them or not. An approved proposal can fail > and be rolled back for technical reasons (e.g.: unexpected issues crop > up at implementation time), but not because random package maintainers > practice obstructionism because they don't like the decision. If you compare this to Debian what exactly is your proposal to change for the better? Kind regards Andreas. -- https://fam-tille.de
Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi, in the light of the previous discussion I have a question to all voters. Due to bug #1066377 more than 30 testing removal warnings hit my mailbox today (I stopped counting after 30). While the Debian Med package clustalo is the only package that's responsible for this due to its Build-Dependency from libargtable2-dev there is quite some dependency tree inside Debian Med team also affecting packages relevant for COVID-19 etc. This small lib is not a key package which is important for all things I'm writing below. Its used as Build-Depends by 6 other packages. Our always busy team member Étienne Mollier provided a patch 10 days ago (thanks again Étienne). The package had its last maintainer Upload -- Shachar Shemesh Sat, 16 Jul 2016 20:45:15 +0300 (Shachar in CC) and a NMU -- Holger Levsen Fri, 01 Jan 2021 17:15:04 +0100 (reproducible build, no changes - in other words no problems since 2016). However, the BTS view of Sanchar might hinting for some inactivity when looking at two RC bugs in other packages: #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm #998987 [src:privbind] privbind: missing required debian/rules targets build-arch and/or build-indep As I wrote to Marc here on this list also the explicit hint to Shachar: Its not about blaming you - I just want to analyse the current situation to act properly. Given that you had no capacity to respond to two bugs that are RC since 2 years makes me wonder how long I need to wait for your OK to a team upload I'm proposing below. I'm perfectly aware that we as volunteers can't be blamed about those things. I simply want to find new ways how to deal with those situations appropriately. Am Thu, Apr 04, 2024 at 12:38:34PM +0200 schrieb Andreas Tille: > > > > > > A. Packages should be maintained on Salsa > > > B. Lets use dh (if possible - I was told there are exceptions) > > > C. Commit to latest packaging standards > > > D. Make more than one person responsible for a package > > > E. General QA work of contributors not mentioned as Maintainer / > > > Uploader > > > > > > > > > 1. Fix vcs_url + vcs_browser (A.) I moved the package to salsa[1] and added VCS fields > > > 2. Fix some bug(s) (E.) I applied the patch from Étienne. > > > 3. Runs Janitor / routine-update which changes (C.) I was running `routine-update -f` > > > 4. Converts to dh (if not yet which I did not checked) (B.) I removed debian/autoreconf.* files which were unneeded with latest dh compat level (and routine-update is doing this). > > > 5. Turn d/copyright into machine readable form (if not yet which > > > I did not checked) (C.) Secure URI in copyright format > > > 6. Finds a team where the package fits into moves the repository > > > to that team space and moves you to Uploaders (D.) I simply sticked to debian/ since I have no idea what team might fit. > I forgot > 7. Add autopkgtest I admit I did not spent time into this. > > 1-5 are just fine. That's what git is for. Either fork the project, > > commit changes, file an MR, or (dor a repository inside the Debian/ > > space), commit to a branch, file an MR. > > Thank you for your opinion. It is very valuable for me to learn what > people consider acceptable. I assume you would consider 7. fine as > well. I guess this is fulfilled. > > Personally, I do prefer having the last word to say what gets into > > the master/main branch and I'd like to at least be consulted before an > > upload. > > If no team is specified this is definitely default behaviour. Shachar is in CC of this mail. > > I might look like a rotten maintainer when you look at my oldest > > packages, > > Absolutely not. When digging into the said resources I have seen way > worse. I'm not here to blame anybody. I'm seeking for solutions. Sorry again for just picking this example which is attached to you (Shachar). I neither wanted to blame Marc about anything in my previous mail nor you in this mail. Its simply the kind of thing that is creating a lot of stress in our team. I could follow the normal NMU procedure but I do not consider this a sustainable solution. It took me about 10-15 min in my lunch break to bring the package into a shape, where other people are able to commit in a convenient way (Salsa, latest packaging standards). > > 6 I would find too intrusive without talking to me first. It's a slap in > > the face, I would probably drop the package as a kneejerk reaction. > > Talking to you is mandatory. I know you for a long time as helpful and > responsive on mailing lists. But assume we are talking about someone > who does not respond (for whatever reason). Could you imagine some > scenario where 6. would be acceptable? I did not uploaded my work but I would like to know what action is considered acceptable by the voters. I repeat that the package is no key package for which I would not consider what I did above. Please simply
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 11:39, Andreas Tille wrote: > > Hi Marc, > > Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber: > > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote: > > "we now use Wayland > > instead of X11", "please don't create your system users with adduser and > > more, use a declarative approach". > > > > At the moment, we simply dont take such decisions. I think that's a > > problem. > > I think I get your point now. Thanks for these examples. You might > have a point in these specific ones but I see Debian leading in other > aspects. > > As far as I know other major distributions do not undertake the time_t > 64bit transition (whether this marks leadership or not is questionable > but it will make us the leading distribution on those architectures in > future). Of course they are, most of the important work lately has been done by SUSE for example, to replace legacy components that will hopelessly break in 2038. Of course they have an advantage in not having to carry around dead architectures, so it's easier. > I'm not well informed about other distributions but seeked the internet > and for instance found some article about reproducible builds from > 2019[2] where Debian and ArchLinux are mentioned frequently but Fedora > is not. I've picked that older article since taking the lead means who > started that effort and I think we are in this game. > > Apropos ArchLinux: I would love if Debian would manage to craft such a > great documentation in Wiki. That's not a "technological" lead but > we've lost the lead in documentation by far which is in my perception a > weaker point than the time we adopt one or the other technical change. > > I think we are doing a good job regarding CI with adding autopkgtests > (but we could do even better for sure). I'm not informed about the > status of CI in other distributions and whether there exists something > like Salsa CI. I'm positively convinced that Debian has reached a level > of complexity which makes CI tests mandatory for every important package > and I would love if we could do the lead here. OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's source control system has a CI integrated with it that is similar to the one we have. Packit is even starting to make its way in upstream projects's CIs, we use it in systemd for example, so that upstream PRs also build and test Fedora packages in Fedora images. We do the same with Debian and autopkgtest btw. > > > > Are our technical > > > > decision-making processes up to today's challenges? > > > > > > Would you mind clarifying this question? We have the CTTE as > > > decision-making instance but I'm not sure whether you are refering to > > > this. > > > > The CTTE is a tie-breaker which is only invoked to resolve a fight. And > > if invoked, the decision takes months. In other sitations, we keep > > fighting in the open, probably doing a GR, which makes the news even > > before we have decided anything. > > > > That's the price we currently pay for being not a commercial entity, > > I fully subscribe to this statement. I don't think commercial entities have anything to do with this. Fedora is not a commercial entity (please, no FUD about RH) and yet it can take decisions and implement them just fine. It's entirely a question of self-organization and what rules we decide for the project. > > so > > that we don't have a project leader who has the power to say "we're > > going to do X", like the board or the managing director of a commercial > > company has. > > I consider the DPL as a "Leader with no power". Convincing a huge > number of volunteers to pull a string into the same direction is a way > harder job than telling employees of a company what to do next. I'm > aware of this challenge. > > > Seriously, I don't how Fedora takes their technical > > decision, but there has to be a reason why they're so far ahead of us > > technologically. > > I need to admit that I (currently) don't know much about Fedora (but I > hope I could fix this in the near future). At Chemnitzer Linuxtage I > took the chance to talk to OpenSUSE and Nix about organisatorical > solutions. There was no booth by Fedora I could show up. In short, Fedora project members elect a technical committee, FESCO. Project members can submit proposals to this committee for project-wide changes, which votes on whether to approve them or reject them. If they are approved, the committee and the proposer are empowered to enact the changes distro-wide - whether individual package maintainers like them or not. An approved proposal can fail and be rolled back for technical reasons (e.g.: unexpected issues crop up at implementation time), but not because random package maintainers practice obstructionism because they don't like the decision.
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > I see a big problem that we do not follow common standards. While we
> > have some teams with strict policies setting those standards internally
> > to a different level of strictness there is no Debian wide consensus
> > about things like
> >
> > A. Packages should be maintained on Salsa
> > B. Lets use dh (if possible - I was told there are exceptions)
> > C. Commit to latest packaging standards
> > D. Make more than one person responsible for a package
> > E. General QA work of contributors not mentioned as Maintainer /
> > Uploader
> >
> > [I will reference these items below by their letters]
> >
> > I'm addressing this in the paragraph "Packaging standards" of my
> > platform. I'm also very concerned about packages who don't get
> > any attention any more ("smelly packages") which has two major
> > reasons:
> >
> > 1. We do not have contributors with free capacity to care for
> > problems in other peoples packages
> > 2. Even if we had those the strict ownership of packages pevents
> > that new contributors can step in. When reading the paragraph
> > about NMUs in developers reference[1] this is probably
> > sensible for actively maintained packages - but what about
> > those packages which do not show any activity for years?
>
> I think this can't just be seen by looking at the statistiks. Many small
> packages do their job and don't need constant attention as long as they
> still build and work.
I agree that pure statistics is not telling the whole story. However,
those statistics give some feeling about the issue which for sure needs
to be verified on case-by-case basis. I can assure you that I usually
inspect the list of smelly packages[1] whether there are hits for my
name (currently one false positive and one package where I'm forced to
use cdbs) but also look for packages I might be able to salvage from
there. I've found some impressive hits for this purpose in the past
that are supporting my point besides stupid statistics.
> ...
> Those three packages I decided not to put work into until there is a
> technical reason for doing so. I do have all three on the radar and they
> will properly move to salsa and be modernized once there will be a
> change to the code or an RC bug regarding packaging. Until then, I have
> more important things to do.
Thanks for going into detail about these which I neither wanted nor
expected in this granularity. I had no doubt that there are more
important things for you. I honestly tried to investigate by using
these examples is the following: In case there might be people out
there who have time and energy to fix this kind of things, how can we
enable them to take this work from your shoulders to enable you
concentrating on more important stuff.
> policyrcd-script-zg2 I should modernize and upload. A few people seem to
> actually use this, and it helps getting rid of the discussions whether a
> distributio should start a daemon right after package installation
> (which we do, and Red Hat based distributions don't, causing irritations
> by people accustomed to Red Hat working with Debian). You got a point
> here.
As I said I did not wanted to make a point about your maintainership.
I simply wanted to discuss existing examples instead of statistics.
> Those bugs are either wontfix, or already fixed in git (not yet uploaded
> because cosmetic), or neglected, right.
I personally tend to upload when I've fixed some bug in Git (even when
cosmetic) to remove noise from BTS. In the said cases it would
specifically helpful to fix VCS information since it is very important
information for other Debian contributors. Before uploading I usually
run `routine-update -f` which is just upgrading to latest standards by
calling Janitor tools and does some other changes to keep up with latest
packaging standards semi-automatically.
> > What would you think if someone would push the following
> > commits and uploads to unstable:
> >
> > 1. Fix vcs_url + vcs_browser (A.)
> > 2. Fix some bug(s) (E.)
> > 3. Runs Janitor / routine-update which changes (C.)
> > 4. Converts to dh (if not yet which I did not checked) (B.)
> > 5. Turn d/copyright into machine readable form (if not yet which
> > I did not checked) (C.)
> > 6. Finds a team where the package fits into moves the repository
> > to that team space and moves you to Uploaders (D.)
I forgot
7. Add autopkgtest
> 1-5 are just fine. That's what git is for. Either fork the project,
> commit changes, file an MR, or (dor a repository inside the Debian/
> space), commit to a branch, file an MR.
Thank you for your opinion. It is very valuable for me to learn what
people consider acceptable. I assume you would consider 7. fine as
well.
> Personally, I do prefer having the last word to say what
Re: Question to all candidates: What are your technical goals
[snipped everything that I don't have an answer for. Neither removal nor
quoting is endorsement or reject of what Andreas said.]
On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> > There are many people who see Debian as a technology project, with the
> > technical goal of producing The Universal Operating System.
> >
> > What are you planning to do to Debian from a technical and technological
> > point of view? What do we well, where do we suck on the technical site?
>
> I see a big problem that we do not follow common standards. While we
> have some teams with strict policies setting those standards internally
> to a different level of strictness there is no Debian wide consensus
> about things like
>
> A. Packages should be maintained on Salsa
> B. Lets use dh (if possible - I was told there are exceptions)
> C. Commit to latest packaging standards
> D. Make more than one person responsible for a package
> E. General QA work of contributors not mentioned as Maintainer /
> Uploader
>
> [I will reference these items below by their letters]
>
> I'm addressing this in the paragraph "Packaging standards" of my
> platform. I'm also very concerned about packages who don't get
> any attention any more ("smelly packages") which has two major
> reasons:
>
> 1. We do not have contributors with free capacity to care for
> problems in other peoples packages
> 2. Even if we had those the strict ownership of packages pevents
> that new contributors can step in. When reading the paragraph
> about NMUs in developers reference[1] this is probably
> sensible for actively maintained packages - but what about
> those packages which do not show any activity for years?
I think this can't just be seen by looking at the statistiks. Many small
packages do their job and don't need constant attention as long as they
still build and work.
> I notived you are maintaining
>
> select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
> vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
> '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like
> '%salsa%') tmp;
> 20
>
> packages on Salsa in various teams. Great! You also have
>
> udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
> WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
> '%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
> source| maintainer |
> uploaders | vcs_browser
>
> --+--+---+--
> apg | Marc Haber |
>| http://git.debian.org/?p=collab-maint/apg.git;a=summary
> console-log | Marc Haber |
>| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
> dnstop | Marc Haber |
>| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
> policyrcd-script-zg2 | Marc Haber |
>| http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
> (4 rows)
>
> I verified on Salsa that all those are imported to debian/ name space on
> Salsa (which is also great - I have seen lots of other packages who are
> not imported to Salsa). It would help if you could sooner or later
> consider uploading those packages.
apg has a dead upstream and will probably have to go. Two years ago, I
decided to move the package to salsa to have it available for reference.
In parallel, I queried the maintainer of the least dead github fork
whether they are planning to take care of the upstream, received no
answer. The only commits that are not in the package are of cosmetic
value and I do not much believe in doing an upload (wasting buildd
resources, mirror bandwidth etc) just for the sake of those cosmetics.
console-log is little more than an init script that needs serious
rewriting to be usable on a systemd system. Probably also a candidate
for removal. I was not aware that Jelmer put the sources on salsa, I
appreciate their efforts.
dnstop I should probably either put up for adoption or have removed as
well. It hasn't seen a release in a decade, the last commit upstream was
two years ago, and I am not running DNS server at scale any more. Also,
I was not aware that the repository was put on salsa by Jelmer, probably
we shold have a mechanism to keep the maintainer of the Debian package
posted when something like that happens.
Those three packages I decided not to put work into until there is a
technical reason for doing so. I do have all three on the radar and they
will properly move to salsa and be modernized once there will be a
change to the code or an RC bug regarding
Re: Question to all candidates: Bits from the DPL?
> "Andreas" == Andreas Tille writes: Andreas> I was told in private that a daily log in Git might be a bit tough but Andreas> I hope to manage. I consider it a good preparation for the monthly Bits. I think I recall inheriting some infrastructure from Chris for maintaining some DPL news that was accessible to DDs or to future DPLs or something, but not in git and not public. Ah, yeah, master.debian.org:/srv/leader/news I used it sometimes, but definitely not daily. I think Chris used it more effectively. I don't remember how I tracked what to cover in my bits emails. I think I did look at the news files, and I also just had a few issues I knew I was going to cover. I also looked back at lea...@debian.org mail to see if there were things happening that I should boost. --Sam signature.asc Description: PGP signature
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> There are many people who see Debian as a technology project, with the
> technical goal of producing The Universal Operating System.
>
> What are you planning to do to Debian from a technical and technological
> point of view? What do we well, where do we suck on the technical site?
I see a big problem that we do not follow common standards. While we
have some teams with strict policies setting those standards internally
to a different level of strictness there is no Debian wide consensus
about things like
A. Packages should be maintained on Salsa
B. Lets use dh (if possible - I was told there are exceptions)
C. Commit to latest packaging standards
D. Make more than one person responsible for a package
E. General QA work of contributors not mentioned as Maintainer /
Uploader
[I will reference these items below by their letters]
I'm addressing this in the paragraph "Packaging standards" of my
platform. I'm also very concerned about packages who don't get
any attention any more ("smelly packages") which has two major
reasons:
1. We do not have contributors with free capacity to care for
problems in other peoples packages
2. Even if we had those the strict ownership of packages pevents
that new contributors can step in. When reading the paragraph
about NMUs in developers reference[1] this is probably
sensible for actively maintained packages - but what about
those packages which do not show any activity for years?
> If we do suck in some technical points, what are you planning to do to
> improve those things?
I would love to see that maintaining packages on Salsa becomes mandatory
and I wonder what might be the best way to approach this. We might
start with some GR about it. But perhaps it is better to start talking
to people. I use UDD as my reference and since I want to hear your
personal opinon I'm just querying for your packages. Its definitely not
about you personally - just a nice example.
I notived you are maintaining
select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
'%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like '%salsa%')
tmp;
20
packages on Salsa in various teams. Great! You also have
udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
'%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
source| maintainer |
uploaders | vcs_browser
--+--+---+--
apg | Marc Haber |
| http://git.debian.org/?p=collab-maint/apg.git;a=summary
console-log | Marc Haber |
| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
dnstop | Marc Haber |
| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
policyrcd-script-zg2 | Marc Haber |
| http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
(4 rows)
I verified on Salsa that all those are imported to debian/ name space on
Salsa (which is also great - I have seen lots of other packages who are
not imported to Salsa). It would help if you could sooner or later
consider uploading those packages. When seeking for other reasons I've
found 11 bugs via
udd=> SELECT id, package, source, arrival, severity, title FROM bugs WHERE
source IN (SELECT DISTINCT source FROM sources WHERE release = 'sid' and
(maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND
vcs_url not like '%salsa%');
which I will not list here to not lengthen this mail. My guess is you
are aware of this but have reasons / time constraints to not act for the
moment. What would you think if someone would push the following
commits and uploads to unstable:
1. Fix vcs_url + vcs_browser (A.)
2. Fix some bug(s) (E.)
3. Runs Janitor / routine-update which changes (C.)
4. Converts to dh (if not yet which I did not checked) (B.)
5. Turn d/copyright into machine readable form (if not yet which
I did not checked) (C.)
6. Finds a team where the package fits into moves the repository
to that team space and moves you to Uploaders (D.)
Assume you will be asked about those changes but you have no time
to answer (for whatever reason). What of those changes is OK for
you and how long would you expect the potential contributor to your
packages to wait until taking action?
> What is your position about technical leadership?
IMHO we could gain/keep technical leadership if we would manage to apply
our technical standards to all the things
Re: Question to all candidates: Bits from the DPL?
Hi Lous-Philippe, Am Tue, Apr 02, 2024 at 04:05:21PM -0400 schrieb Louis-Philippe Véronneau: > Jonathan's latest "Bits from the DPL" entry reminded me of how much I like > those :) > > What are your thoughts on the format? > > If you are elected, do you plan to publish regular "Bits"? If not, how do > you plan to communicate with the rest of the project with regards to the > work you are doing? Quoting my platform: I intend to maintain a daily log in a public Git repository, provided the information can be shared with a public audience. Additionally, I will send a monthly summary to debian-devel-announce to keep you informed about my activities and progress. I was told in private that a daily log in Git might be a bit tough but I hope to manage. I consider it a good preparation for the monthly Bits. Kind regards Andreas. -- https://fam-tille.de
Question to all candidates: What are your technical goals
Dear Candidates, There are many people who see Debian as a technology project, with the technical goal of producing The Universal Operating System. What are you planning to do to Debian from a technical and technological point of view? What do we well, where do we suck on the technical site? If we do suck in some technical points, what are you planning to do to improve those things? What is your position about technical leadership? Are our technical decision-making processes up to today's challenges? Thanks for your consideration to answer these questions despite platforms containing language about this topic. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Question to all candidates: Bits from the DPL?
Hello! Jonathan's latest "Bits from the DPL" entry reminded me of how much I like those :) What are your thoughts on the format? If you are elected, do you plan to publish regular "Bits"? If not, how do you plan to communicate with the rest of the project with regards to the work you are doing? Cheers! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On 27/03/24 04:54, Thomas Goirand wrote: Hi, As you know, there's a large amount of money sleeping in SPI account for Debian. Do you have ideas on how to spend it? From Jonathan's mail, I think we do not have too much money unused now. Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? As I mentioned in some previous questions, I would be interested to hear about ideas to make good use of our money. But I would not be taking decisions on spending "big" amount of money without much discussion within the Debian community. Based on some experience we had in our Free Software Community of India, I have learned that hosting services is a task that require good amount of effort and time for maintenance. If we do not have a enough volunteers to handle them, it will result in burnout and eventually the services die. Let us take up this topic after the elections (if I become the DPL) and evaluate the pros and cons before committing. Also, I found very annoying that we don't have enough buildd, or that the reproducible build project doesn't have as much hardware as they would like. Would it be ok to spend another 100k USD for this kind of things. Generally speaking, spending on hardware in my opinion is a good investment. Jonathan in his mail mentioned that some amount of money was spent recently for hardwares by DSA. So let us revisit this request later, discuss with DSA and decide. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On 3/27/24 08:51, Andreas Tille wrote: Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? While I personally have no use case for this I'm perfectly open for spending money on this and love to discuss this either on debian-project or debian-private (if private discussion seems to be appropriate). However, I see an important requirement to consider this money well spent: We need a team who cares for the maintenance of this cloud. I do not think that we can simply add to the workload of DSA. And I want it to be a real team and not a 1-person team. Quickly, because I do not want to dive too much in the topic. Adding workload to DSA isn't the plan. I also have other persons that raised their hands as volunteers. Let's discuss this after the vote ! :) Cheers, Thomas Goirand (zigo)
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On 3/27/24 11:25, Pierre-Elliott Bécue wrote: Hi, Thomas Goirand wrote on 27/03/2024 at 00:24:30+0100: Hi, As you know, there's a large amount of money sleeping in SPI account for Debian. Do you have ideas on how to spend it? Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? Please, let's take some time to think about the implications of spending a shitload of money to buy hardware that we wouldn't know where to host, and that would require a load of maintenance and time. FYI, if I didn't go forward with the project, that we've been discussing with Jonathan over at least 3 years, is because I have no idea where to host it. I have clearly stated that having this hosted at *my* company (ie: Infomaniak) is *not* what I want to do to avoid any type of conflict of interest. I am staying firm with the idea that I shouldn't do that. Though if anyone has a clue where we should do it, we can open such a discussion (yeah, after the vote: my question was if Andrea was happy with this type of project, not how and where we should to it). Since I have failed to find where to host, maybe I should open the topic with a wider audience, in the hope to have some suggestions. So, let's not get further on this topic and let's reopen it soon. If any discussion should arise on these matters, I'd rather them to occur not as a platform for a DPL candidate but after a reasonable discussion with the concerned parties, eg, DSA. No. The DSA people have already stated multiple times that they do not want to be integrated in such a project. Let's do this without them if this is still the case. If you asked me, I'd say I would regret not to do it with the DSA, but it's entirely their call, and it's also probably good to try not to be overloaded with complicated clusters like OpenStack. Also, I found very annoying that we don't have enough buildd, or that the reproducible build project doesn't have as much hardware as they would like. Would it be ok to spend another 100k USD for this kind of things? Same, with slightly less concern regarding hardware volume and maintenance. Yeah, DSA and other teams (ports maintainers?) should be involved. From a DD perspective, it's just very annoying to have to wait days, and sometimes even weeks, to have a package built on all arch. IMO, we should address this, in some way or another. Cheers, Thomas Goirand (zigo)
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi! On 2024/03/27 12:25, Pierre-Elliott Bécue wrote: Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? > Please, let's take some time to think about the implications of spending a shitload of money to buy hardware that we wouldn't know where to host, and that would require a load of maintenance and time. If any discussion should arise on these matters, I'd rather them to occur not as a platform for a DPL candidate but after a reasonable discussion with the concerned parties, eg, DSA. I'm trying not to respond to too many mails here because I don't want to take away too much attention from the candidates, but I also don't think we have a problem of money heaping up anymore. Across the project, our financial needs are mostly met, and it helps having some reserve cash for a rainy day. Also on the DSA front, they have just filed a request two weeks ago for upgrades at UBC in the range of $110-$160k, so it's not like we're spending nothing on hardware either! Also, every single hardware request over the last 4 years (whether from DSA or from a DD) has been approved. I hope that's something that our new DPL will continue doing so for every reasonable request going forward as well! -Jonathan
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi, Thomas Goirand wrote on 27/03/2024 at 00:24:30+0100: > Hi, > > As you know, there's a large amount of money sleeping in SPI account > for Debian. Do you have ideas on how to spend it? > > Would you be ok spending 100k USD on buying hardware for a new Debian > cloud, for example? I've always volunteered to operate it for Debian, > but it never went through, because I haven't spent time to find where > to host it and so on, but highvoltage liked the idea. Do you like this > idea? Do you think it'd be useful for Debian? Please, let's take some time to think about the implications of spending a shitload of money to buy hardware that we wouldn't know where to host, and that would require a load of maintenance and time. If any discussion should arise on these matters, I'd rather them to occur not as a platform for a DPL candidate but after a reasonable discussion with the concerned parties, eg, DSA. > Also, I found very annoying that we don't have enough buildd, or that > the reproducible build project doesn't have as much hardware as they > would like. Would it be ok to spend another 100k USD for this kind of > things? Same, with slightly less concern regarding hardware volume and maintenance. > For some packages of mine, the current shared runners are too slow to > even run time-based tests of openvswitch for example... What about the > Salsa CI? Couldn't we pay some cloud providers to have faster shared > runners? It wouldn't be hard to hook them. -- PEB signature.asc Description: PGP signature
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi Thomas, Am Wed, Mar 27, 2024 at 12:24:30AM +0100 schrieb Thomas Goirand: > As you know, there's a large amount of money sleeping in SPI account for > Debian. Do you have ideas on how to spend it? While I admit that I'm not well informed about the status of the acount currently I'm perfectly open to interesting suggestsions. In general I think donators want to see their money spent for the progress of Debian and not for filling up some bank account. > Would you be ok spending 100k USD on buying hardware for a new Debian cloud, > for example? I've always volunteered to operate it for Debian, but it never > went through, because I haven't spent time to find where to host it and so > on, but highvoltage liked the idea. Do you like this idea? Do you think it'd > be useful for Debian? While I personally have no use case for this I'm perfectly open for spending money on this and love to discuss this either on debian-project or debian-private (if private discussion seems to be appropriate). However, I see an important requirement to consider this money well spent: We need a team who cares for the maintenance of this cloud. I do not think that we can simply add to the workload of DSA. And I want it to be a real team and not a 1-person team. > Also, I found very annoying that we don't have enough buildd, or that the > reproducible build project doesn't have as much hardware as they would like. > Would it be ok to spend another 100k USD for this kind of things? I'd happily spent money on infrastructure we really need which includes buildd and reproducible builds. I'm also fine with stregthening Debci and Salsa CI if needed. But also here the question is: Just permitting the usage of money is one thing. We also need people to do the actual grunt work of buying, installing and maintaining the hardware. If this is granted I'm perfectly fine with it. > For some packages of mine, the current shared runners are too slow to even > run time-based tests of openvswitch for example... What about the Salsa CI? As I mentioned above I'm happy to make Salsa CI more performant. > Couldn't we pay some cloud providers to have faster shared runners? It > wouldn't be hard to hook them. Paying some cloud providers to host shared runners for us might be one answer to my requirement that there are actual people who care and not only money thrown at some hardware. It needs to be well thought / discussed what services can be delegated to some cloud providers and what needs to be Debian hosted. For Salsa CI I do not see any constraints since its just building publicly accessible code. Kind regards Andreas. -- https://fam-tille.de
Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi, As you know, there's a large amount of money sleeping in SPI account for Debian. Do you have ideas on how to spend it? Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? Also, I found very annoying that we don't have enough buildd, or that the reproducible build project doesn't have as much hardware as they would like. Would it be ok to spend another 100k USD for this kind of things? For some packages of mine, the current shared runners are too slow to even run time-based tests of openvswitch for example... What about the Salsa CI? Couldn't we pay some cloud providers to have faster shared runners? It wouldn't be hard to hook them. Cheers, Thomas Goirand (zigo) P.S: To other DDs reading: feel free to voice your opinion too.
Re: Question to all candidates: Ongoing/future legal projects
Hi Felix, It seems there's much more behind the scenes than I happen to know... So, with the little context I have, I keep believing that your reimbursement request is appropriate. And, for *just* not following the proper procedure, such a request shouldn't be ultimately refused, IMO. Bests, -- Tiago On Tue, Mar 29, 2022 at 08:47:10PM -0700, Felix Lechner wrote: > Hi Tiago, > > On Sun, Mar 27, 2022 at 11:09 AM Tiago Bortoletto Vaz > wrote: > > > > Given that Jonathan, after lots of research as he describes in this > > thread, has stated that such request never reached him, can you clarify > > how can you have even complied to a request for more information from him? > > > > Also, if that's the case, why didn't you try to reach him in private at > > the time rather than bringing it to -vote months later, during an DPL > > campaign period in which you are both candidates? > > > > In my view, your request was totally eligible and could/should be > > quickly approved. > > Look, the discussion with Richard was about the process for > disbursements. I like the idea of committees that are on schedule and > open to the public. > > Despite the collateral damage Jonathan suffered for the missing > reimbursement (which people in power have to endure) I did not intend > to embarrass him, yet that's where we are taking this thread. > > Jonathan is a busy guy. In fact, he is so busy he too would benefit if > other folks handled the disbursements. It would be a win-win for > everyone. > > My messages may also have gotten stuck in Jonathan's spam filter. > > It furthermore seems that I did not follow the proper process when > filing my request, as Paul Wise pointed out. > > Either way, you challenged me for the true record. Below, you will > find the exchange you are interested in. I redacted both of Jonathan's > responses in case he wrote them. As you can see, I wrote a lot in > private, but was ineffective. > > Similar to my other responses, I am committed to transparency when possible. > > For context you will need to know that my internal hindrances with > operating lintian.d.o—which we resurrected after years of spotty > service—did not start (or end) with the misplaced reimbursement. In > RT#8464 from November 2020, you will find a partial record of the > dispute. (The ticket contains one of the few irate emails I have > written in Debian; it may have contributed to my DAM warning.) To this > day, there has been nothing but obstruction. > > In my mind, the missing reimbursement simply made that point one more time. > > Jonathan witnessed some of my issues, but he did not cause them. In > Debian, too much power is held away from the public eye. We have Setec > Astronomy. Hence my open and public committees. > > Thanks for supporting my reimbursement request! > > Kind regards, > Felix Lechner > > -- Forwarded message - > From: Felix Lechner > Date: Wed, Nov 3, 2021 at 7:45 AM > Subject: Re: Spending Debian money, [redacted] > To: Jonathan Carter > > Hi Jonathan, > > On Sun, Aug 9, 2020 at 9:01 AM Jonathan Carter wrote: > > > > [excerpt of posting to debian-private] > > For over a year, I contemplated writing this request. As part of my > contributions to Debian I operate the website lintian.d.o. Untarring > and scanning the archive uses lots of resources. The service is > heavily disk-bound. > > It would help to upgrade one of my machines to an NVMe SSD. The > machine also needs more memory (currently 24 GB). I would not normally > make the upgrades. Would the project please help out with the proposed > purchase? > > The details in the amount of approximately US$217 are below. Thanks! > > Kind regards > Felix Lechner > > * * * > > SAMSUNG (MZ-V8V1T0B/AM) 980 SSD 1TB, $120 > Dual M.2 PCIE Adapter for SATA or PCIE NVMe, $16 > Patriot 16GB(2x8GB) Viper III DDR3 1600MHz CL9, $60 > Subtotal $196 > Sales Tax $21 > Total $217 > > All amounts are in US dollars. The seller is Amazon.com. > > -- Forwarded message - > From: Jonathan Carter > Date: Thu, Nov 4, 2021 at 11:57 AM > Subject: Re: Spending Debian money, [redacted] > To: Felix Lechner > > [redacted for privacy] > > -Jonathan > > -- Forwarded message - > From: Jonathan Carter > Date: Fri, Nov 5, 2021 at 11:53 AM > Subject: Re: Spending Debian money, [redacted] > To: Felix Lechner > > Hi Felix > > [redacted for privacy] > > -Jonathan > > -- Forwarded message - > From: Felix Lechner > Date: Fri, Nov 5, 2021 at 12:59 PM > Subject: Re: Spending Debian money, [redacted] > To: Jonathan Carter > > Hi Jonathan, > > On Fri, Nov 5, 2021 at 11:53 AM Jonathan Carter wrote: > > > > [redacted for privacy] > > The website consists of three parts. There is a web server, which > [redacted] hosts presently; a database on my personal VPS; and the > machinery that generates the data. > > Some time ago, [redacted] offered to host the database (part > [redacted]). I believe I
Re: Question to all candidates: GDPR compliance review
On Sat, Apr 02, 2022 at 12:21:24PM +0200, Christian Kastner wrote: > On 2022-04-02 10:55, Adrian Bunk wrote: > > Where does our Privacy Policy[1] describe personal data where Debian and > > the community team are joint controllers? > > > Where does our Privacy Policy describe personal data where Debian and > > DAM are joint controllers? > > Has it been established yet that Debian fits the definition of a > controller as per Article 4 lit. 7 GDPR? > > I can see DAM, or CT, or the DPL possibly being controllers. What is the identity of DAM or CT? Likely each individual team members is a controller. If a person has suffered material or non-material damage as a result of a GDPR infringement, each controller or processor can be held liable for compensation of the entire damage (Article 82(4)). > But > without some form of officially recognized organization, I don't see how > Debian could be one. "Debian" doesn't even have an address, you couldn't > even determine which data protection authority has jurisdiction. What is "The Debian Project" in the Privacy Policy[2]? Providing the identity and the contact details of the controller is mandatory for processing of personal data (Articles 13(1)(a) and 14(1)(a)), failure to do so is subject to administrative fines of up to 20 Million Euro (Article 83(5)(b)). > This is just one of the things that, I think, would be a lot simpler if > Debian would register as an organization, hence my question [1] to the > candidates. >... This is likely required and desirable, as was also discussed in the thread starting with [3]. cu Adrian [1] Here in Finland the threshold for gift tax is 5000 Euro. [2] https://www.debian.org/legal/privacy [3] https://lists.debian.org/debian-project/2022/03/msg8.html
Re: Question to all candidates: GDPR compliance review
Hi Adrian, On Fri, 2022-04-01 at 23:48 +0300, Adrian Bunk wrote: > Will this handwritten note be available through > contributors.debian.org? > > If the personal information in the handwritten note did not come > directly from the person, who at Debian is responsible to ensure that > the person gets informed automatically about the existence of the > note when it is written? > > Same questions, with "local file" instead of "handwritten note". > > Same questions, with "stored on a Debian machine". I am fairly confident you store personal data about me. Could you please provide some information about it? Do you publish a privacy policy? What data do you store? (Please don't send a copy to the list; private mail is okay.) On what legal basis is the data processed? Where is the data physically stored? Who besides you has access to the data? For what purposes might the data be used? What retention period is defined for the data? Why was I not informed that data about me is being stored? Ansgar
Re: Question to all candidates: GDPR compliance review
On 2022-04-02 10:55, Adrian Bunk wrote: > Where does our Privacy Policy[1] describe personal data where Debian and > the community team are joint controllers? > Where does our Privacy Policy describe personal data where Debian and > DAM are joint controllers? Has it been established yet that Debian fits the definition of a controller as per Article 4 lit. 7 GDPR? I can see DAM, or CT, or the DPL possibly being controllers. But without some form of officially recognized organization, I don't see how Debian could be one. "Debian" doesn't even have an address, you couldn't even determine which data protection authority has jurisdiction. This is just one of the things that, I think, would be a lot simpler if Debian would register as an organization, hence my question [1] to the candidates. [1] https://lists.debian.org/debian-vote/2022/03/msg00135.html
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 09:25:46PM +0200, Jonathan Carter wrote: > On 2022/04/01 20:28, 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? > > > [1]https://lists.debian.org/debian-project/2022/03/msg8.html > > That mail asks a bunch of very, very broad questions. My opinion is that > it's better to direct specific problems at the data protection team as > noodles suggested. Then let's start with some very specific questions based on the email I just sent to Sam: Where does our Privacy Policy[1] describe personal data where Debian and the community team are joint controllers? On what legal basis is the data processed? Where is the data physically stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? How are people being informed when data about them is being stored? Where does our Privacy Policy describe personal data where Debian and DAM are joint controllers? On what legal basis is the data processed? Where is the data physically stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? How are people being informed when data about them is being stored? These are specific questions about items that are supposed to be written in our Privacy Policy. > -Jonathan cu Adrian [1] https://www.debian.org/legal/privacy
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 04:57:38PM -0600, Sam Hartman wrote: > > "Adrian" == Adrian Bunk writes: > Adrian> Your "services" approach does not work for the non-trivial > Adrian> cases where Debian might be a (joint) controller of personal > Adrian> data. > > Adrian> The Debian Community Team promises confidentiality regarding > Adrian> personal information they receive about other people,[1] > Adrian> which conflicts with the legal obligation of informing the > Adrian> person about whom personal information is being processed or > Adrian> stored. > > Based on legal advice I received while acting as DPL, the above is not > correct. > Most of the information the community team process is not information we > would need to disclose in response to a GDPR subject access request. Where does Debians Privacy Policy[1] describe this personal data where Debian and the community team are joint controllers? Where is the data stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? > Debian has already dealt with at least one subject access request that > dealt significantly with information held by DAM in its role as a > delegated team. Where does Debians Privacy Policy[1] describe this personal data where Debian and DAM are joint controllers? > Some of that information was responsive; some of that information was > covered by exceptions. This covers only a part where Debian might be compliant with the law. >... > > If the personal information in the handwritten note did not come > > directly from the person, who at Debian is responsible to ensure that > > the person gets informed automatically about the existence of the note > > when it is written? >... Exceptions might cover not having to disclose the contents of the data in some cases, but I would still expect that the person has to be informed that information exists. See [2] for background in what context I started thinking about these issues. >... > The data protection team was looped into the process we and our lawyer > used in responding to the request. > The data protection team (and my successor as DPL) received copies of > the legal advice we received. Are you saying that all handling of personal data in Debian is following the law, or are you just trying to make me stop asking inconvenient questions? I am feeling stonewalled and stalled regarding any attempts of receiving a review of handling of personal data in Debian, with a schedule that would be appropriate for potential illegal activity. I would like to emphasize and repeat [3,4]: IANAL and it is more likely than not that some things I am writing are not correct. What I want is to see the results of a proper review by an actual lawyer. If I fail to achieve visible progress on this topic inside Debian, the obvious option for getting a second opinion is to make a formal request for all personal data about me in Debian, followed by asking my questions to the Finnish Data Protection Ombudsman. If everything I am writing is just wrong, then I will be told just that by the ombudsman. > --Sam cu Adrian [1] https://www.debian.org/legal/privacy [2] https://lists.debian.org/debian-project/2022/03/msg00010.html [3] https://lists.debian.org/debian-project/2022/03/msg8.html [4] https://lists.debian.org/debian-vote/2022/03/msg00270.html
Re: Question to all candidates: GDPR compliance review
On Fri, 1 Apr 2022 22:16:55 +0300 Adrian Bunk wrote: > One option would be to outsource this work to our paid GDPR lawyer. Is there any option to cooperate with other FLOSS organizations? They would have the same issue and we may be able to share it and costs ;) -- Hideki Yamane
Re: Question to all candidates: GDPR compliance review
> "Adrian" == Adrian Bunk writes: Adrian> Your "services" approach does not work for the non-trivial Adrian> cases where Debian might be a (joint) controller of personal Adrian> data. Adrian> The Debian Community Team promises confidentiality regarding Adrian> personal information they receive about other people,[1] Adrian> which conflicts with the legal obligation of informing the Adrian> person about whom personal information is being processed or Adrian> stored. Based on legal advice I received while acting as DPL, the above is not correct. Most of the information the community team process is not information we would need to disclose in response to a GDPR subject access request. Debian has already dealt with at least one subject access request that dealt significantly with information held by DAM in its role as a delegated team. Some of that information was responsive; some of that information was covered by exceptions. The data protection team was looped into the process we and our lawyer used in responding to the request. The data protection team (and my successor as DPL) received copies of the legal advice we received. --Sam
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 09:18:53PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > Who will fulfill the request within the legal limit of one month if > > a person sends an email to data-protect...@debian.org asking whether > > Debian is a (joint) controller of any data about this person, and > > if yes requests a copy of all data? > > To make this easier for services and users, we recommend that services > use contributes.debian.org and that they then request the data from the > individual services and then point people at that. Your "services" approach does not work for the non-trivial cases where Debian might be a (joint) controller of personal data. The Debian Community Team promises confidentiality regarding personal information they receive about other people,[1] which conflicts with the legal obligation of informing the person about whom personal information is being processed or stored. Debian might be a joint controller if a member of the Debian Community Team stores personal information about a person in a handwritten note on paper (see [2] as an example of case law about handwritten notes)[3]. Will this handwritten note be available through contributors.debian.org? If the personal information in the handwritten note did not come directly from the person, who at Debian is responsible to ensure that the person gets informed automatically about the existence of the note when it is written? Same questions, with "local file" instead of "handwritten note". Same questions, with "stored on a Debian machine". Discussing such questions with a lawyer early is usually cheaper and less hassle than waiting until someone brings them up in a court case. > Cheers, cu Adrian [1] https://wiki.debian.org/Teams/Community [2] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:62017CJ0025=EN [3] This court case was under the previous Directive from 1995, but the basic definitions are unchanged in the GDPR legislation that replaced it.
Re: Question to all candidates: GDPR compliance review
On 2022/04/01 20:28, 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? [1]https://lists.debian.org/debian-project/2022/03/msg8.html That mail asks a bunch of very, very broad questions. My opinion is that it's better to direct specific problems at the data protection team as noodles suggested. -Jonathan
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 08:46:42PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > 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? > > I don't think that's something the DPL could commit to, even if they > wanted to. First of all, what you're asking for is not what the data > protection team is there for, secondly, neither the DPL nor anyone else > has the ability to commit to anyone in Debian doing anything on any > particular timeline. > > If that's what you're looking for, you're looking for a company with > staff, not a volunteer project. One option would be to outsource this work to our paid GDPR lawyer. > Cheers, cu Adrian
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 07:40:02PM +0200, Tollef Fog Heen wrote: >... > This isn't the role of the data protection team, though, any more than > owner@bugs is responsible for fixing all the bugs in all the packages. > I'm quite happy to act as a redirector (as per the first part of the > delegation) as well as advising service owners. I have below-zero > interest in auditing all our services and tracking everything relevant > to data privacy throughout Debian. >... Who will fulfill the request within the legal limit of one month if a person sends an email to data-protect...@debian.org asking whether Debian is a (joint) controller of any data about this person, and if yes requests a copy of all data? If there is no reply within one month, the person can request an order from the local supervisory authority (e.g. [1] is the online form for such requests in my country of residence). > Cheers, cu Adrian [1] https://tietosuoja.fi/en/find-out-whether-the-data-protection-ombudsman-can-help-you-rights
Re: Question to all candidates: GDPR compliance review
]] Adrian Bunk > Who will fulfill the request within the legal limit of one month if > a person sends an email to data-protect...@debian.org asking whether > Debian is a (joint) controller of any data about this person, and > if yes requests a copy of all data? To make this easier for services and users, we recommend that services use contributes.debian.org and that they then request the data from the individual services and then point people at that. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
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: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 07:02:15PM +0200, Jonathan Carter wrote: > Hi Adrian Hi Jonathan, >... > I'm not sure bringing in the lawyer as a first step is optimal, they are > expensive and will probably tell us a lot of things we already know. IMHO > it's better to do some initial groundwork, compile a list of issues that we > need help on, and then take that to the lawyer for further input. usually trying to solve legal issues without consulting a lawyer early ends up being more expensive. >... > So, I would appreciate it if the data protection team could look into all of > the issues we know of in Debian, but I'd also like there to be a process > where people can file issues with the data protection team. >... > So, I think it's more important to take care of known issues and low hanging > fruit before getting a lawyer involved. I also think it's a good idea to > make it easy to file issues as they are found, and would like to know if the > Data Protection team has any ideas or if they would consider implementing > anything like the above. It might not have been intended, but to me this comes across like stalling, trying to avoid addressing the big problems - we all know from our BTS that "filing issues" does not necessarily imply that anything will ever happen. 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? > -Jonathan cu Adrian [1] https://lists.debian.org/debian-project/2022/03/msg8.html
Re: Question to all candidates: GDPR compliance review
]] Adrian Bunk > 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? I don't think that's something the DPL could commit to, even if they wanted to. First of all, what you're asking for is not what the data protection team is there for, secondly, neither the DPL nor anyone else has the ability to commit to anyone in Debian doing anything on any particular timeline. If that's what you're looking for, you're looking for a company with staff, not a volunteer project. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Question to all candidates: GDPR compliance review
]] Jonathan Carter > So, I would appreciate it if the data protection team could look into > all of the issues we know of in Debian, but I'd also like there to be > a process where people can file issues with the data protection > team. I'll admit I had to search a bit to find the data-protection > email address, it doesn't seem to prominently feature anywhere on our > website. www.debian.org → Contact → privacy (not sure why the footer is missing from the front page) and it's there, so while not _very_ prominently, it's not very hidden either. > But it would be great if it was clear that someone could file > a bug with a tag, or whether they should use the data-protection > alias, so that it's possible to file and keep track of data protection > issues that need to be resolved. This isn't the role of the data protection team, though, any more than owner@bugs is responsible for fixing all the bugs in all the packages. I'm quite happy to act as a redirector (as per the first part of the delegation) as well as advising service owners. I have below-zero interest in auditing all our services and tracking everything relevant to data privacy throughout Debian. I can't speak for the other team members, but I have not seen them express enthusiasm about this idea either. Even if you got a team that would perform that tracking and auditing, what good would it be? They wouldn't be able to compel any service owners to fix their service. Cheers, -- Tollef Fog Heen, for himself UNIX is user friendly, it's just picky about who its friends are
Re: Question to all candidates: GDPR compliance review
Hi Adrian (I'm including the data-protection team, perhaps they can expand on your question or comment on my feedback) On 2022/03/31 22:08, Adrian Bunk wrote: The discussion starting in [1] is about privacy in Debian with a focus on the GDPR of the European Union. It started with the GDPR, in my country we have POPIA, in California there's CCPA, there are now over a dozen similar legislations (and I suspect more countries will be implementing them as time goes by). Fortunately they seem to mostly overlap, so complying to at least GDPR properly should make it a lot easier to comply in the other territories that we operate. When I first read through a GDPR guideline, I was quite happy about it because for the most part, it forces websites to do things that I consider a bare minimum when it comes to the safety of users' data. Personally, I think it would be great if we exceed the expectations of these legislations around the world. There seems to be a general agreement that privacy in Debian falls short of the legal minimum requirements at least in the EU. Even the exact scope of the problem is not clear. Question to all candidates: If elected, will you ask our Data Protection team and our GDPR lawyer to jointly do a review of all handling of personal data in Debian regarding GDPR compliance, and make the results of the review available to all developers? I'm not sure bringing in the lawyer as a first step is optimal, they are expensive and will probably tell us a lot of things we already know. IMHO it's better to do some initial groundwork, compile a list of issues that we need help on, and then take that to the lawyer for further input. I can also think of some examples where we processed user data that you didn't mention. As one example, we used to use the DebConf wiki quite a bit to organize events, and those all got turned into static pages. People who signed up and provided information (potentially contact details, where they were at certain dates, etc) couldn't have possibly known that the data they entered would've been later archived as publicly accessible read-only material later on, well at least not by us. So, I would appreciate it if the data protection team could look into all of the issues we know of in Debian, but I'd also like there to be a process where people can file issues with the data protection team. I'll admit I had to search a bit to find the data-protection email address, it doesn't seem to prominently feature anywhere on our website. But it would be great if it was clear that someone could file a bug with a tag, or whether they should use the data-protection alias, so that it's possible to file and keep track of data protection issues that need to be resolved. So, I think it's more important to take care of known issues and low hanging fruit before getting a lawyer involved. I also think it's a good idea to make it easy to file issues as they are found, and would like to know if the Data Protection team has any ideas or if they would consider implementing anything like the above. -Jonathan
Re: Question to all candidates: GDPR compliance review
Hi, On Thu, 31 Mar 2022 23:08:41 +0300 Adrian Bunk wrote: > If elected, will you ask our Data Protection team and our GDPR lawyer to > jointly do a review of all handling of personal data in Debian regarding > GDPR compliance, Yes. > and make the results of the review available to all > developers? I'm positive about it but not sure since I don't understand the negative side effects of showing it to all. Transparency is important for us, but sometimes "just all open" approach causes some trouble. -- Hideki Yamane
Re: Question to all candidates: rotation on positions of power
Hi Charles, On Wed, 23 Mar 2022 21:51:44 +0900 Charles Plessy wrote: > I expect a term limit to increase rotation on the positions of power, > with the following benefits: > > - reduce the risk of burn-out of the delegates, > > - motivate fresh people to have the ambition to serve in these >positions, because it becomes predictable when driving seats become >available, > > - motivate the current delegates to put their own replacement as part >of their planning, making us more resilient to sudden (or chronic) >unavailabilities, > > - increase the chances that those of us who keep a strong involvement >over many years diversify their experience, knitting our different >subgroups into a more harmonious society. > > - increase our chances that challenging ideas accepted. Okay, thank you. I agree with all of above. > In brief, everything good (and everything bad) that "more turnover" is > expected to bring in most of social structures where we evolve outside > Debian. "Mixing" people is necessary to maintain its organization. And don't forget, "just only limiting" is not mixing. With "fresh blood" is what we want :) Then we need more information about current status of those works, we ask them to give "bits from" mails. -- Hideki Yamane
Re: Question to all candidates: GDPR compliance review
Hi Adrian, On Thu, Mar 31, 2022 at 1:24 PM Adrian Bunk wrote: > > The discussion starting in [1] is about privacy in Debian with a focus > on the GDPR of the European Union. > > There seems to be a general agreement that privacy in Debian falls > short of the legal minimum requirements at least in the EU. > > Even the exact scope of the problem is not clear. > > Question to all candidates: > > If elected, will you ask our Data Protection team and our GDPR lawyer to > jointly do a review of all handling of personal data in Debian regarding > GDPR compliance, and make the results of the review available to all > developers? Yes. The release of any findings may be redacted, or may be a summary. Recipients may be required to sign a confidentiality agreement coupled with an indemnity in the event of a breach, and a release of claims, or both. In all cases, I reserve the right to act on the advice of counsel—but with an explanation to you. I will treat you the same way that I would wish to be treated if our roles were reversed. I am committed to transparency when possible. Kind regards, Felix Lechner
Question to all candidates: GDPR compliance review
The discussion starting in [1] is about privacy in Debian with a focus on the GDPR of the European Union. There seems to be a general agreement that privacy in Debian falls short of the legal minimum requirements at least in the EU. Even the exact scope of the problem is not clear. Question to all candidates: If elected, will you ask our Data Protection team and our GDPR lawyer to jointly do a review of all handling of personal data in Debian regarding GDPR compliance, and make the results of the review available to all developers? Thanks Adrian [1] https://lists.debian.org/debian-project/2022/03/msg8.html
Re: Question to all candidates: Ongoing/future legal projects
On 2022/03/30 07:33, Paul Wise wrote: On Tue, 2022-03-29 at 20:47 -0700, Felix Lechner wrote: It furthermore seems that I did not follow the proper process when filing my request, as Paul Wise pointed out. My reference to the Hardware/Wanted wiki page was referring to the procedure for after you have bought hardware, no longer need it and want to pass it on to someone else. Admittedly the page also includes info about posting hardware wishlists, but that section of the page doesn't really apply to your case since it is more for a Debian service, so just buying hardware and getting a reimbursement is a better process, this is documented in the section on hosting, which I've just rewritten to be a bit clearer. Just in case it's still not clear to anyone, the process for approval for an expense is at: https://wiki.debian.org/Teams/DPL/Reimbursement PS: I also just added mention of hardware purchases to the page and uses of Debian money to the MemberBenefits page. I saw the diff e-mail, thanks! -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
On Tue, 2022-03-29 at 20:47 -0700, Felix Lechner wrote: > It furthermore seems that I did not follow the proper process when > filing my request, as Paul Wise pointed out. My reference to the Hardware/Wanted wiki page was referring to the procedure for after you have bought hardware, no longer need it and want to pass it on to someone else. Admittedly the page also includes info about posting hardware wishlists, but that section of the page doesn't really apply to your case since it is more for a Debian service, so just buying hardware and getting a reimbursement is a better process, this is documented in the section on hosting, which I've just rewritten to be a bit clearer. PS: I also just added mention of hardware purchases to the page and uses of Debian money to the MemberBenefits page. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question to all candidates: Ongoing/future legal projects
Hi Tiago, On Sun, Mar 27, 2022 at 11:09 AM Tiago Bortoletto Vaz wrote: > > Given that Jonathan, after lots of research as he describes in this > thread, has stated that such request never reached him, can you clarify > how can you have even complied to a request for more information from him? > > Also, if that's the case, why didn't you try to reach him in private at > the time rather than bringing it to -vote months later, during an DPL > campaign period in which you are both candidates? > > In my view, your request was totally eligible and could/should be > quickly approved. Look, the discussion with Richard was about the process for disbursements. I like the idea of committees that are on schedule and open to the public. Despite the collateral damage Jonathan suffered for the missing reimbursement (which people in power have to endure) I did not intend to embarrass him, yet that's where we are taking this thread. Jonathan is a busy guy. In fact, he is so busy he too would benefit if other folks handled the disbursements. It would be a win-win for everyone. My messages may also have gotten stuck in Jonathan's spam filter. It furthermore seems that I did not follow the proper process when filing my request, as Paul Wise pointed out. Either way, you challenged me for the true record. Below, you will find the exchange you are interested in. I redacted both of Jonathan's responses in case he wrote them. As you can see, I wrote a lot in private, but was ineffective. Similar to my other responses, I am committed to transparency when possible. For context you will need to know that my internal hindrances with operating lintian.d.o—which we resurrected after years of spotty service—did not start (or end) with the misplaced reimbursement. In RT#8464 from November 2020, you will find a partial record of the dispute. (The ticket contains one of the few irate emails I have written in Debian; it may have contributed to my DAM warning.) To this day, there has been nothing but obstruction. In my mind, the missing reimbursement simply made that point one more time. Jonathan witnessed some of my issues, but he did not cause them. In Debian, too much power is held away from the public eye. We have Setec Astronomy. Hence my open and public committees. Thanks for supporting my reimbursement request! Kind regards, Felix Lechner -- Forwarded message - From: Felix Lechner Date: Wed, Nov 3, 2021 at 7:45 AM Subject: Re: Spending Debian money, [redacted] To: Jonathan Carter Hi Jonathan, On Sun, Aug 9, 2020 at 9:01 AM Jonathan Carter wrote: > > [excerpt of posting to debian-private] For over a year, I contemplated writing this request. As part of my contributions to Debian I operate the website lintian.d.o. Untarring and scanning the archive uses lots of resources. The service is heavily disk-bound. It would help to upgrade one of my machines to an NVMe SSD. The machine also needs more memory (currently 24 GB). I would not normally make the upgrades. Would the project please help out with the proposed purchase? The details in the amount of approximately US$217 are below. Thanks! Kind regards Felix Lechner * * * SAMSUNG (MZ-V8V1T0B/AM) 980 SSD 1TB, $120 Dual M.2 PCIE Adapter for SATA or PCIE NVMe, $16 Patriot 16GB(2x8GB) Viper III DDR3 1600MHz CL9, $60 Subtotal $196 Sales Tax $21 Total $217 All amounts are in US dollars. The seller is Amazon.com. -- Forwarded message - From: Jonathan Carter Date: Thu, Nov 4, 2021 at 11:57 AM Subject: Re: Spending Debian money, [redacted] To: Felix Lechner [redacted for privacy] -Jonathan -- Forwarded message - From: Jonathan Carter Date: Fri, Nov 5, 2021 at 11:53 AM Subject: Re: Spending Debian money, [redacted] To: Felix Lechner Hi Felix [redacted for privacy] -Jonathan -- Forwarded message - From: Felix Lechner Date: Fri, Nov 5, 2021 at 12:59 PM Subject: Re: Spending Debian money, [redacted] To: Jonathan Carter Hi Jonathan, On Fri, Nov 5, 2021 at 11:53 AM Jonathan Carter wrote: > > [redacted for privacy] The website consists of three parts. There is a web server, which [redacted] hosts presently; a database on my personal VPS; and the machinery that generates the data. Some time ago, [redacted] offered to host the database (part [redacted]). I believe I met all their requirements (most notably, packaging semver [1] for bullseye), but no one has responded to my most recent message from October 4. At this point, I believe I earned the right to suspect that the delay was intended to provoke me into writing another angry letter, but none is coming. It would therefore be fine to proceed with the database. (The website will also work better if DAM kicks me out, as [redacted] suggested.) The database is currently hosted on a VPS with 1 GB of RAM, which is under dimensioned. I already offer reduced services. Having received no response from [redacted], I approached [redacted] about the
Re: Question to all candidates: how is Debian doing?
Hi Ted, On Tue, Mar 29, 2022 at 1:39 PM Theodore Ts'o wrote: > > I'll note that you spent a lot of time about how the council would > appoint a chair and vice-chair, create bylaws, meet monthly, etc. > > However you didn't really answer the question regarding what the > authorities that the Strategy Council would have. You've said that > the strategy council would expand on your answers that were given in > the top of this thread --- but then what? > > If the Strategy Council were to decide that a strategy might be, say, > "a mouse should put a bell on the cat", how would that strategy be > carried out? Debian is a volunteer organization some have said, > "do-ocracy". So I'm not sure what you, as the DPL, would do with the > conclusions that might be made by such a Strategy Council? In my reading of Lucas's original questions, he merely probed the thinking of the candidates. Lucas did not express a concern that any of us would fail for lack of authority. My responses were meant to answer his questions. At the same time, I will answer your questions as well. The idea behind the committees is to establish, by experiment, that two or more heads think better together than one alone. Large parts of the project still operate according to the "strong maintainer" model, so that's a significant paradigm shift. The committees provide a soft counterweight that cares about the project as a whole. A better group spirit alone will be a noticeable advance for Debian. As to your specific concern about how strategic conclusions might be used, a project leader can benefit from the advice in many ways. For example, I would make sure that my own actions work for us in the long term, and not against us. As a passionate optimist, I may also need an occasional reality check from our best and brightest. Since everything is public, all members can do the same. Perhaps most significantly, I hope to present the membership with a wide range of novel and creative proposals. The findings of a Strategy Council could create a sense of urgency—a rare sentiment in Debian—to embrace new ideas. In short, the Strategy Council will help us, as a group, to get unstuck in many ways. That's how we will get stuff done. Thank you for your challenging question! Kind regards, Felix Lechner
Re: Question to all candidates: how is Debian doing?
On Thu, Mar 17, 2022 at 01:57:59PM -0700, Felix Lechner wrote: > Hi Lucas, > > On Thu, Mar 17, 2022 at 12:52 PM Lucas Nussbaum wrote: > > > > Interesting. What would be the composition, roles, duties of that > > Strategy Council ? > > Like all committees and boards I envision, the Strategy Council should > have at least five but no more than twelve members. I personally like > nine, if you can get that many volunteers I'll note that you spent a lot of time about how the council would appoint a chair and vice-chair, create bylaws, meet monthly, etc. However you didn't really answer the question regarding what the authorities that the Strategy Council would have. You've said that the strategy council would expand on your answers that were given in the top of this thread --- but then what? If the Strategy Council were to decide that a strategy might be, say, "a mouse should put a bell on the cat", how would that strategy be carried out? Debian is a volunteer organization some have said, "do-ocracy". So I'm not sure what you, as the DPL, would do with the conclusions that might be made by such a Strategy Council? Cheers, - Ted
Re: Question to all candidates: Ongoing/future legal projects
On Sun, 2022-03-27 at 18:34 +0200, Jonathan Carter wrote: > One thing people have been really concerned about when asking for Debian > to buy hardware is, is what happens to the hardware after they're done > with it? So far I've just told them that they can try to pass it on to > another DD who might want/need it (there's some wiki page for this that > I think is rarely used) The wiki page for this is part of Hardware/Wanted and neither the list of hardware available to be donated nor the list of hardware that people wish for have ever been used. It seems that people currently get wanted hardware and donate unwanted hardware in other ways, perhaps via web services oriented towards that or mailing lists. The wiki page might need more promotion, integration with the DPL hardware buying guidelines or possibly just removal from the wiki entirely. https://wiki.debian.org/Hardware/Wanted#Available_hardware -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question to all candidates: Ongoing/future legal projects
Hi Richard (2022.03.27_20:17:48_+) > > The only cases of waste I know of happens when people ask for > > sponsorship for DebConf and then hotel space is made for them (and > > possibly other expenses) and then they just don't show up without any > > heads-up. Even those are rare, but it's the only instances of really > > wasting any money that I can think of. > > Reimbursing people after the fact would avoid that. (If they didn't show up, > they wouldn't get a reimbursement.) But I suppose in some/many/all cases > where Debian is paying, it is because the person can't afford the cost. So > they might not be able to float it even temporarily. If so, then I guess > that might just be a risk we have to accept. Thankfully you're saying these > things are rare. That is how we handle DebConf travel bursaries (reimbursement after the event), except in exceptional circumstances. However, there are other expenses allocated (e.g. hotel rooms organised by the conference) that the conference has to pay for, whether or not they are used. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Question to all candidates: Ongoing/future legal projects
On 3/27/22 11:14, Jonathan Carter wrote: The only cases of waste I know of happens when people ask for sponsorship for DebConf and then hotel space is made for them (and possibly other expenses) and then they just don't show up without any heads-up. Even those are rare, but it's the only instances of really wasting any money that I can think of. Reimbursing people after the fact would avoid that. (If they didn't show up, they wouldn't get a reimbursement.) But I suppose in some/many/all cases where Debian is paying, it is because the person can't afford the cost. So they might not be able to float it even temporarily. If so, then I guess that might just be a risk we have to accept. Thankfully you're saying these things are rare. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
Hi Felix, On 2022-03-24 8:18 p.m., Felix Lechner wrote: [...] > > For example, I requested $217 for a one-time SSD & RAM upgrade to help > operate lintian.d.o in November of 2021. My request was not granted. I > didn't even receive a response from Jonathan (other than a request for > more information, with which I complied) even though I followed up on > my request. Given that Jonathan, after lots of research as he describes in this thread, has stated that such request never reached him, can you clarify how can you have even complied to a request for more information from him? Also, if that's the case, why didn't you try to reach him in private at the time rather than bringing it to -vote months later, during an DPL campaign period in which you are both candidates? In my view, your request was totally eligible and could/should be quickly approved. Thanks, -- Tiago
Re: Question to all candidates: Ongoing/future legal projects
Hi Richard On 2022/03/24 22:17, Richard Laager wrote: The disbursements that I've heard about seem to be relatively "small potatoes" things. Is there some huge wasteful spending occurring that I've missed? Most of it is small potatoes (typically less than $1000, typically for hardware or travel or meetings). Some are really big potatoes, when DSA does big upgrades it can be 10s of thousands of dollars. The only cases of waste I know of happens when people ask for sponsorship for DebConf and then hotel space is made for them (and possibly other expenses) and then they just don't show up without any heads-up. Even those are rare, but it's the only instances of really wasting any money that I can think of. One anti-pattern I've seen with spending money (not Debian, but elsewhere) is that a group will spend e.g. $10x worth of time debating $x expense. Sometimes that is appropriate, if you're confronting a new class of spending that will be repeated and you need to develop a policy to apply. But often, it's just a waste because people want to bikeshed. Oh I've seen this in Debian. 2 seperate meetings about the price of cups (that could potentially save a few $10) where the collective salaries of the people in the room would be over a hundred times that for one hour. Especially in DebConf people want to save money, and it's great, but I like to encourage them to spend a bit more where it can save a lot of volunteer time, and also where it can increase quality (I consider it wasteful if we, for example, buy a t-shirt so cheap that the only thing someone would want to do with it is wash their car with). In cases like those spending a bit more is using our money more efficiently. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Paul On 2022/03/26 01:27, Paul Wise wrote: We have these documents related to that: https://wiki.debian.org/Teams/DPL#Money https://wiki.debian.org/Teams/DPL/AskingForMoney https://wiki.debian.org/Teams/DPL/SponsoringGuidelines These were written by Stefano Zacchiroli in 2010 when he was DPL, he added the hardware guidelines in 2012 and since then only very minor edits have been made by non-DPL folks. Are there any expenditure requests you have approved that would not fit into the categories listed on the existing expenditure guidelines? They all fit into those guidelines, except for the DebConf20 proceeds that we donated to Framasoft for PeerTube development, that was the one notable exception, this was handled transparently and with consensus, so I doubt that would be a problem. What changes to the existing expenditure guidelines would you make? I'd like it to be a bit more consistent depending on who's DPL. So far I've approved every request unless there's a good reason no to (like if it goes against our guidelines, or against the obligations that our TOs have when working with money). In the past I've seen some DPLs make some relatively small approvals quite complicated, and also denying some requests that I think should've been approved. My goal is also to give a DD more confidence in sending through a request, I often have more work because someone tells me that they need something but then I have to do the work to convince them that it really is ok to submit a request. I want to make it easier for DDs to spend the money that was donated to them to make Debian better, and I squarely disagree with Felix that it should become any harder for DDs to spend money. One thing people have been really concerned about when asking for Debian to buy hardware is, is what happens to the hardware after they're done with it? So far I've just told them that they can try to pass it on to another DD who might want/need it (there's some wiki page for this that I think is rarely used), or sell it and donate the proceeds back to Debian, or just keep it as a spare in case they need it again. But it would be nice to have this in writing. I also make a point of telling people that Debian is /not/ responsible for the hardware. If it breaks or needs maintenance, then it's their responsibility to take care of it (although, they could also submit another request for that if needed). So, in some ways I'd like to make it simpler, but also add some more information, build some more confidence for someone who needs to make a request, and have some more policy that applies to the DPL so that it's more consistent based on who's DPL. And if a new DPL doesn't agree with it, they can also just update it again with a notice going out to the project. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
On Fri, 2022-03-25 at 11:41 +0200, Jonathan Carter wrote: > I still want to work towards having an expenditure policy, ... > The idea would be that there's some clear document that makes it > really easy for someone to know whether they can apply for something > or not, and I think if it hits a few checklist items that makes it a > braindead yes, then we shouldn't even require DPL approval. We have these documents related to that: https://wiki.debian.org/Teams/DPL#Money https://wiki.debian.org/Teams/DPL/AskingForMoney https://wiki.debian.org/Teams/DPL/SponsoringGuidelines These were written by Stefano Zacchiroli in 2010 when he was DPL, he added the hardware guidelines in 2012 and since then only very minor edits have been made by non-DPL folks. Are there any expenditure requests you have approved that would not fit into the categories listed on the existing expenditure guidelines? What changes to the existing expenditure guidelines would you make? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question to all candidates: how is Debian doing?
Hi Lucas On 2022/03/17 17:54, Lucas Nussbaum wrote: As someone who used to care a lot about Debian, but who hasn't been able to pay much attention to the project lately, I was wondering: I don't think anyone would hold it against you that you've got busy with other stuff, having a life outside Debian is also considered very healthy these days. How is Debian doing currently? Excellent question! A few weeks ago I saw a headline "Is Mozilla ok?", and while I've thought about it on different levels for a while, it was the first time that I thought in the exact words "Is Debian OK!?" and mean to write something about it (possibly in a blog post, possibly in a "bits from the DPL" mail), but as with this mail, it ended up in various forms of drafts and I never made it half way with it, at least not yet. So starting with a tl;dr, I think Debian is doing ok. It's not doing great, but it is ok. When we ask how Debian is doing, it's also useful to qualify what we're asking. Is the Debian project (our structure, project members, larger community...) ok? Is the Debian distribution (what features our users need, severity of bugs, are we living up to our promises, etc...) ok? On the positive side, we are chugging along quite well. Packages (and lots of new packages) get uploaded, old crud eventually gets deleted (last release was pretty good in this front), bugs get fixed, since 2005 the project has managed to release every 2 years, the website team has great plans to make the website more friendly (*poke to www team to make some public update please*), we finally have a functioning community team (after some iterations and speedbumps), we now have the fasttrack project (although still quite young) to deal with things that move to fast for our usual archives, we're slowly but surely improving community processes that people have complained about for a while (like our current and previous GR to improve voting). Our finances are also really good, our donors show lots of confidence in us. Our corporate sponsors are already great, but I'm constantly amazed by the generosity of our individual donors! There are people who donate a $1000 at a time, some a few $100 every month, and sometimes even a sporadic $4 donation from the same person. It's all very valuable and appreciated! One person even donated $100,000 worth of shares to Debian (was worth $140,000 when I checked last week) which was extremely generous. Even though we've been spending a lot, our available funds are also the highest they've ever been, last year we surpassed the $1m mark in available funds for the first time. That's great. As DPL, that allowed me to feel comfortable saying yes to every single request every DD has made (which I did, and even some none-DDs. I'll focus on the challenging aspects further down since that is a seperate question. What are the recent successes I might have missed? I'll list just a few things since you got busy, there's probably a lot more. We're getting a bit better at working with industry. We have a person from Lenovo helping out with hardware support on their latest hardware, we just today had a DD join from Microsoft, and Microsoft also covered our LWN subscriptions for the last year (thanks!). There's lots of ways big Linux users out there are helping us out, Hetzner gave us a huge discount on our backup server hosting, Lenovo gave us a significant discount on some servers we bought for DSA hosted stuff, and the list goes on. Our local groups initiative is also taking form again. I can't wait to see more from this, covid put a real dampener on this, but between the Debian reunion even in Germany and DebConf22, I hope there will be some great local team packs made that can be sent around the world well before the end of the year. We've moved from Alioth to Salsa (GitLab instance) in 2017. This created a big leap forward in how easy it is to make contributions to Debian. Since then, Gnome, KDE, and many other free software projects have also implemented a GitLab instance, it's now a very familiar and common way to do things in the free software world, and I think this was a significant and important change for us, even though it came with its own set of speedbumps and challenges too. We've gained a riscv64 port. Along with the lowrisc project to make a fully open source CPU, it opens up the possibility to have a truly and fully free hardware and software stack using Debian. It seems like it may still be some years before you could easily buy a phone/e-reader/router/laptop/desktop/server/etc with a riscv64 cpu that can run Debian, but the foundations are being laid, and I consider that critically important. Hardware is increasingly being locked down, and we don't know how long it will be before you have to contact your manufacturer in order to get an unlock code in order to install an alternative operating system on a typical laptop (as
Re: Question to all candidates: Ongoing/future legal projects
On 2022/03/25 11:41, Jonathan Carter wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. That's odd, I usually approve them fast (as in, within 24h) because it's a quick and trivial mail, but I can't find your request in my reimbursements folder at all. I'm in meetings now but will take a look later on if it reached the dpl-archives at all. It's not in the dpl mail archives either (nothing from you in November, no request nor a follow-up). I even checked the rest of the year, mails from you on other topics in other months are there though. I've asked the treasurers to check if they have seen your request too, but from what I can tell in my local folders and on the leader@ archives, it doesn't seem that your request ever reached me. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Felix On 2022/03/25 02:18, Felix Lechner wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. That's odd, I usually approve them fast (as in, within 24h) because it's a quick and trivial mail, but I can't find your request in my reimbursements folder at all. I'm in meetings now but will take a look later on if it reached the dpl-archives at all. My idea for a Disbursements Committee was thus born by a simple desire for greater accountability (or, at a minimum, a response). Plus, if elected, I could never issue that $217 check to myself. I disagree about some of your previous statements to make it more difficult to spend money, I still want to work towards having an expenditure policy, which I still hoped to finish the last month or so, but there was just really too much going on. The idea would be that there's some clear document that makes it really easy for someone to know whether they can apply for something or not, and I think if it hits a few checklist items that makes it a braindead yes, then we shouldn't even require DPL approval. So, I would go for making it even easier to spend money than not to. During my 2 terms we went from having around ~$750k in available funds to having about ~$1.25m now. Every time I mention what we've been spending on (like DSA upgrades, hardware for DDs, etc), we get more donations. As long as this is the case, I have no problem with DDs spending any money they want to if it helps them make Debian better. After all, this is literally the only reason why someone donates money to Debian in the first place. So, I don't believe that the Debian funds should be preserved like some kind of treasure. We should make it as easy as possible for people to give us money, and as easy as possible for DDs to spend money, all within our legal and social frameworks, of course. As for your question about "huge wasteful spending," yes, I do worry about Debian's expenditures in light of Jonathan's comment that he is happy to "give a lawyer a lot of money." [3] Happy is a loaded word that you chose there. If I have to spend money on lawyers to protect the project and its members I will do so without hesitation. I'd /rather/ not have to spend that at all, and find it disappointing that you would even hold that against me. I have worked with teams of lawyers. They get expensive fast. Well, at least there's one thing we agree on. Either way, the right person to address your question is Jonathan, whom I copied as a courtesy. Jonathan ran on financial transparency platforms in both the 2020 election [4] and again in 2021. [5] Besides the updates I've sent out on our financial status every few months, that's not something that will get better soon in the next term. That's to no fault of me (or a next DPL), I've had a bunch of meetings with the treasurer team and TOs to talk about this, and there's a lot of things that need to be fixed along the way in order for us to get the accounting that we need. I'm sure we'll get there. Our TOs have indicated that they are willing to switch accounting systems, use the same expense codes, etc to help make it easier to aggregate data much faster (as in, possibly even almost real-time). That's a whole rabbit hole on itself, but I do believe having a basic incorporation of Debian, along with better agreements with our TOs will be a good starting point to get our financial reporting on the standards that we want them. -Jonathan
Question to all candidates: Code of Conduct and Community Team - how do you feel about them?
Hi Andy, On Sat, Mar 19, 2022 at 12:36 PM Andrew M.A. Cater wrote: > > We've had the Code of Conduct for about eight years now and the Community Team > for about as long. There are still significant differences about how some > people feel about them, despite the Code of Conduct having been adopted by the > Project as a whole. > > How do _you_ feel about the Code of Conduct - and the role of a Community > Team? > > More widely: where something is adopted by the Project but opposition remains > - > how would you deal with differences of opinion and attempt to reconcile > different viewpoints to consensus? Sorry about the delayed response. I had to think about a good way to balance the parts. First off, I'll point out that you recently received a delegation to the Community Team. [1] Please accept my congratulations! Like some recent questions about legal matters here, your question may also not belong in the public realm. According to Debian custom, our disciplinary process is entirely private and generally not even open to the accused. My answer here can never be complete, but like before—feathers and all—I'll try to do my best. The Code of Conduct reads great but I disagree with how it is applied. I think it's one of those proverbial cases where "the way to h--- is paved with good intentions." My concerns revolve mostly about the Code's arbitrary and capricious enforcement, which appears to apply only to some folks and never to people in leadership positions (except for me, more below). I also think the Code should be simpler. I would prefer something like George Carlin's "Seven Words You Can't Say on TV" (warning, offensive) [2] plus maybe another dozen words or so. Personally, I dislike "wtf" a lot, but it is popular with some of my friends. Your team, however, is taking the opposite approach. You are making the Code longer and even more open-ended. Earlier today, you posted a message [3] with a link to what appears to be your team's proprietary interpretation [4] of our Code of Conduct. Did that text receive any kind of community review? To me, your "interpretation" looks too pliable to serve as a reliable basis for any disciplinary action. It is "a living document" and offers several "non-exhaustive lists." It could hardly be more clear that the rules are of your own team's making and subject to your adjustment, as needed. Ideally, I'd like to see some rules governing the conduct of the Community Team, as well. For example, I found it worrisome that you investigate members. In January of 2021, I received an unsolicited email that I perceived as fishing: "I don't know if other incidents have happened since this, but I wanted to know if everything was ok from your point of view." At the time, it seemed like the person was being considered for a delegation. The message read like a background check to me. I declined to cooperate with the investigation, and never told the affected member. The delegation went to someone else. I am also uncomfortable that you, as a Community Team member, would look to the candidates for answers. Maybe I would be your boss, but you should really seek input from the people. I plan to listen to the members. In Fremont, we hold monthly "Coffee with the Cops" events to foster trust and stronger community ties. At those events, I like to tease the Chief of Police that the library has many books on how to reach a "consent of the governed." I wish that our Community Team, too, would embrace better relationships with the public. You should especially reach out to your critics. Please appease them—or explain to me why they are crazy—and you won't have any problems with me. Despite any worries you may have, my goal is not to abolish the Debian Account Managers or to get rid of the Community Team. I would like to cure Debian of what I perceive to be a dangerous and persistent social condition. As outlined in Eckart Tolle's books (especially, the second) no task is more hazardous than to show a society its own mirror. I, too, sometimes pick the wrong words. Please help me with that. Let's make Debian a happier place together! Finally, this reply would not be complete if I did not address my own situation. By running, I ceded some rights to my privacy when I applied for the job. As potentially your sole elected representative, my own conduct is a matter of public interest, even if I do not like it. In the second half of 2021, I was censured by the Debian Account Managers (DAM) for an interaction on IRC. I do not wish to re-litigate it here or anywhere else. I also ask that no one else does, please. At the same time, I believe that voters should be free to discuss their candidate's flaws without any fear of reprisal. After careful consideration, I hereby declassify all parts of my private censure to which I could reasonably have rights, but please without violating the rights of others. (Yes, that includes my goofy letter with the video from "Ferris Bueller's Day
Re: Question to all candidates: Ongoing/future legal projects
On 3/24/22 19:18, Felix Lechner wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. I would be interested to hear why that was not approved. On its face, that seems reasonable. As for your question about "huge wasteful spending," yes, I do worry about Debian's expenditures in light of Jonathan's comment that he is happy to "give a lawyer a lot of money." [3] I think you're taking that completely out of context. The comment was "I [w]as hoping we could just [pay] a lawyer...and they could deal with it." This follows "it turned out that the legal work around it was much hairier and involved than I had previously anticipated". So he was hoping this could be delegated to a lawyer, but it turned out that it still took a bunch of work from our side (him). You're focusing on the "..." bit of "a lot of money", which is just a reference to how lawyers are expensive. [3] https://lists.debian.org/debian-vote/2022/03/msg00137.html -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
Hi Richard, On Thu, Mar 24, 2022 at 1:17 PM Richard Laager wrote: > > The disbursements that I've heard about seem to be relatively "small > potatoes" things. Is there some huge wasteful spending occurring that > I've missed? I don't know. As an outside candidate, I received no confidential briefings. SPI's website publishes data that is in monthly aggregate form [1] but I am not sure how to read it. I also looked for consolidated virtual accounts on the Debian Treasurer's website [2] but could not find any. Do the amounts have to be large in order to matter to people? For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. My idea for a Disbursements Committee was thus born by a simple desire for greater accountability (or, at a minimum, a response). Plus, if elected, I could never issue that $217 check to myself. As for your question about "huge wasteful spending," yes, I do worry about Debian's expenditures in light of Jonathan's comment that he is happy to "give a lawyer a lot of money." [3] I have worked with teams of lawyers. They get expensive fast. Either way, the right person to address your question is Jonathan, whom I copied as a courtesy. Jonathan ran on financial transparency platforms in both the 2020 election [4] and again in 2021. [5] For any of your follow-up comments not quoted above, I perceived your opinions to be final. Please allow me to let your voice stand on its own. Thank you for your constructive follow-up questions! Kind regards, Felix Lechner [1] https://www.spi-inc.org/treasurer/ [2] https://wiki.debian.org/Teams/Treasurer [3] https://lists.debian.org/debian-vote/2022/03/msg00137.html [4] https://www.debian.org/vote/2020/platforms/jcc [5] https://www.debian.org/vote/2021/platforms/jcc
Re: Question to all candidates: registering Debian as an organization
On 3/24/22 15:45, Sam Hartman wrote: "Richard" == Richard Laager writes: Richard> On 3/20/22 07:10, Felix Lechner wrote: >> If we accidentally formed a General Partnership, as has been >> suggested elsewhere Richard> Yes, that would be really dumb for a number of reasons. The problem is that at least in the US, you can accidentally default to a general partnership. Effectively, if you are doing things together, and it cannot be shown what you have instead, and mumble mumble I'm not a lawyer, a court may conclude you are a general partnership. So, it's more what steps have you taken to avoid being considered a general partnership? Unfortunately I cannot point to a lot of these steps for Debian. If that's true, and I cannot say intelligently either way as IANAL, then that feels like a very strong reason that we _need_ to incorporate. I have done a tax-exempt filing with the IRS. I'd be happy to discuss that with someone if that is helpful to anyone in the future. (At the moment, I'm not sure whether I'd feel comfortable volunteering to do such a filing for Debian.) -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: registering Debian as an organization
> "Richard" == Richard Laager writes: Richard> On 3/20/22 07:10, Felix Lechner wrote: >> If we accidentally formed a General Partnership, as has been >> suggested elsewhere Richard> Yes, that would be really dumb for a number of reasons. The problem is that at least in the US, you can accidentally default to a general partnership. Effectively, if you are doing things together, and it cannot be shown what you have instead, and mumble mumble I'm not a lawyer, a court may conclude you are a general partnership. So, it's more what steps have you taken to avoid being considered a general partnership? Unfortunately I cannot point to a lot of these steps for Debian.
Re: Question to all candidates: registering Debian as an organization
On 3/20/22 07:10, Felix Lechner wrote: If we accidentally formed a General Partnership, as has been suggested elsewhere Yes, that would be really dumb for a number of reasons. I have friends who are or were high-ranking officials at the UN. With the project's permission, I might explore finding a home for Debian there. Would the UN be an appropriate potential home for our noble and selfless efforts? IMO, very much no. Subject to actual legal advice, I think the obvious answer is a U.S. 501(c)(3), which is what SPI is. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Ongoing/future legal projects
On 3/20/22 11:58, Felix Lechner wrote: I would not be comfortable granting financial requests, other than on an emergency basis, without some type of community review. The disbursements that I've heard about seem to be relatively "small potatoes" things. Is there some huge wasteful spending occurring that I've missed? One anti-pattern I've seen with spending money (not Debian, but elsewhere) is that a group will spend e.g. $10x worth of time debating $x expense. Sometimes that is appropriate, if you're confronting a new class of spending that will be repeated and you need to develop a policy to apply. But often, it's just a waste because people want to bikeshed. I might ask you, Richard, to serve on my Disbursements Committee together with someone I perceive as an equally strong person but otherwise different from you in some way. A small Appointments Committee could help me figure out who would be a good counterweight. This approach certainly plenty of merit. The devil is in the details, though. If the group is roughly evenly split, then having appointees evenly split to counterbalance each other is appropriate. If the wider group is 80:20, 90:10, or 99:1 on an issue, then picking one from each side unfairly weights the minority position. Maybe that's okay or even desirable (to protect the minority) at 80:20 and a minority position that's reasonable. But it's certainly not good at 99:1 where the 1% position is insane. (I'm not thinking of any particular issue here.) For contentious topics, the debate over disbursements would automatically be compartmentalized to your tiny committee without burdening the entire project. ... The moderating effect grows with the size of your committee. This seems naive. If this principle were true, then political strife in society would disappear because we've tasked our elected representatives with dealing with these issues. We all know that isn't the case, even with bodies the size of a state/national legislature. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Question to all candidates: Code of Conduct and Community Team - how do you feel about them?
On 20 March 2022 09:56:53 UTC, Hideki Yamane wrote: >Hi, > >On Sat, 19 Mar 2022 19:34:03 + >"Andrew M.A. Cater" wrote: >> We've had the Code of Conduct for about eight years now and the Community >> Team >> for about as long. There are still significant differences about how some >> people feel about them, despite the Code of Conduct having been adopted by >> the >> Project as a whole. >> >> How do _you_ feel about the Code of Conduct - and the role of a Community >> Team? > > Well, we have the CoC, but all we do not read and think about it repeatedly, > contrast to DFSG and Social Contract because the CoC itself is a kind of > "common sense", IMHO. > > CoC itself is good, however, we've just created it - have the form but not > the spirit (in Japanese "仏作って魂を入れず"). If we want to use it effectively, > we should do some training during the onboarding process (and it's better to > do it for existing members in each several years). We need more communication > about it with our contributors. > > > We need a Community Team to deal with some troubles for the project, and > they do hard work (thank you), but I need more transparency about what they > are doing (and did). Maybe it would be a sensitive and difficult thing but > it's a necessary thing. > > > >> More widely: where something is adopted by the Project but opposition >> remains - >> how would you deal with differences of opinion and attempt to reconcile >> different viewpoints to consensus? > > That is like a law - our parliament adopts something, but opposition remains > ;) > And we are an all different people and have a unique opinion, sometimes > conflict with each other. Yes, there is a "gap," so all we apparently should > recognize it. Currently, it's not (to me, at least). > > > And if someone would do some violation to CoC, just banning is not healing. > Asking them to go for counseling by professionals with project money is > better, > IMO. We are good at coding, writing, making some systems - but not counselors. > After dealing with some cognitive trouble, then re-start talking. > > Maybe before and during their duties, the community team members would be > better > to get counseling since dealing with such trouble make them sick (or something > wrong feelings), IMHO. > > > To summarize: > - Make the situation clear: what's wrong, and what it should be. > - Train ourselves: to think about what is CoC and why we need it > - We don't have to do all the work by only ourselves. > Ask the professionals that we are not good at (of course I'll do so :) > > >-- >Hideki Yamane > -- mail: alast...@sceal.ie, matrix: @alastair:sceal.ie Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Question to all candidates: rotation on positions of power
Le Thu, Mar 17, 2022 at 04:27:49PM +0900, Hideki Yamane a écrit : > > I'm sorry, but could you explain "what do you want to improve with > a term limit"? Good evening Hideki, I expect a term limit to increase rotation on the positions of power, with the following benefits: - reduce the risk of burn-out of the delegates, - motivate fresh people to have the ambition to serve in these positions, because it becomes predictable when driving seats become available, - motivate the current delegates to put their own replacement as part of their planning, making us more resilient to sudden (or chronic) unavailabilities, - increase the chances that those of us who keep a strong involvement over many years diversify their experience, knitting our different subgroups into a more harmonious society. - increase our chances that challenging ideas accepted. In brief, everything good (and everything bad) that "more turnover" is expected to bring in most of social structures where we evolve outside Debian. Cheers, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Question to all candidates: registering Debian as an organization
On Mon, Mar 21, 2022 at 11:40:36AM +0100, Gard Spreemann wrote: > > If there was a single Debian foundation, Debian members would be split > > between those that are in the juridiction of the foundation and those > > that are not and the former would be inevitably advantaged. > > Would moving such an entity in the face of adverse legal conditions, if > and when they arise, be a difficult operation? (I have absolutely no > idea myself) Moveing money between countries is always a major problem. That is why it is best for Debian to have money in different countries registered with different organization. At minimum you can reimburse expenses in the local money, which is always much cheaper. Cheers, -- Bill. Imagine a large red swirl here.
Re: Question to all candidates: registering Debian as an organization
On 2022-03-21 12:05, Holger Levsen wrote: > On Mon, Mar 21, 2022 at 09:41:49AM +0100, Christian Kastner wrote: >> A common pattern to address this within the open source world is to >> create a non-profit legal entity, e.g. the FSF Foundation or the GNOME >> Foundation. > > or SPI? SPI is Debian and 39 other projects, as far as I can see. I think Debian should have its own identity.
Re: Question to all candidates: registering Debian as an organization
On Mon, Mar 21, 2022 at 09:41:49AM +0100, Christian Kastner wrote: > A common pattern to address this within the open source world is to > create a non-profit legal entity, e.g. the FSF Foundation or the GNOME > Foundation. or SPI? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.) signature.asc Description: PGP signature
