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
Debian Project Leader election 2024: First call for votes
Hi,
This is the fist call for votes for the DPL election of 2024.
Voting period starts 2024-04-06 00:00:00 UTC
Votes must be received by 2024-04-19 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2024/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2024".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 3.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "None of the above" as more desirable
than the unacceptable choices, or you may rank the "None of the above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None of the above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None of the above" choice by the voting software).
Finally, mail the filled out ballot to: leader2...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
9c605edd-40a5-469c-9489-cbf80ac05970
[ ] Choice 1: Andreas Tille
[ ] Choice 2: Sruthi Chandran
[ ] Choice 3: None Of The Above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBGYPJG0BEADDE7JDmXCIKi05UqF/OMIdHu/5RvDPc5TwtGofnF9ov9bsXIll
dA+lRLz58tvkuibfF2xFi4ZXMmmmSaZkQ/KlZC9tk+fs7J4+WemGS19srzVWF3Hk
3Vcad0VoV5kJtpatgL7iR2xRvzgvMgDs5baRnehSJ+pTtp9fCLQDXl9tmI48a8cF
HNyTiXPUpY+0mR69HsuywuCmiU6bgH9kksJNbstbzCVewp9bqHOSWavU4loi9TCp
jk0EjfisrJNBopXF/m0gxozZD2V+2JrxRDnn8e2vHZ3ljq34t7YRy9yTD8ey74ym
HutRq2EOwWVjRlc8vVpmbvX7F7FzPdrgw0wLFBCxwMUxcHOX+m9IvM2aYl2oeyM8
YE0yAX0FqUO75ujCYr4y9x5RIKKVxjdzv5Paiy4YBPiWWHxt+5JhrV+l6Vlrj3oT
s+RGp8NyeVd+jZmnY2FJsr20ZMovPSD8xcTvOrv8LPRlZpqSP2R93gMX6txZGiNa
/vvqY4d7xb9VUSxDN/3scb8ihBLEGnvkvk2h6hcDRxbX7cTjiWtmqDy8vn/e/fRQ
Z3QJToaiCfhcJNApBD5KPKjch+di8RlOfhrSb+1UMJrV2RjWRPQaXskGyIrRhXiy
Tpaq895OX6b0jDeFH7cbQuZh2XTVJKZ7FUDw8pqgmrq2S0BuW2gLb1zxQQARAQAB
tCpEUEwgdm90ZSAyMDI0IDxsZWFkZXIyMDI0QHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmYPJG0CGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
ENK7zila6Q4lujIP/39ZmDz3vgx7s2tO5NqSP5U+HPNYTs1sO+kicqTyHeKsNRJY
Yfp6Crjx++rREATOaE0lfPWvjtYCx5qYedgxkdSJNMk8F7VWgF3Rf4Ze2WaDRpdF
aJSePI/TrSqU2mCrR9/G+GSeuZiIQIRRmPVOTqZaJzpd9OYcXQXO99mrlcZPNgTS
R0dd8aZg49qHUNtVuRuHeK+b9b0t1+xzwb8d5OiNPc092SfO5b6b+IoJw3vsbrYb
byJPRIse7JF+zZntblCJOeaA87AnicOF/ilQNA8msRRo7CvtRrxEK9zyef6KB7eB
Ir71Qu3RYrfE4AyWkWeWAmtYGmcyH5SIVnahoq2XZ3Rf7UbN/4j4dmHNymtkv5GR
WCg0ixj8S4HvLdyJusoRs/F4IbcJlJjJzq7arDw/WXWbWz0oomm8W7wtP1lU5icL
14hTUYuuvc0MeWSVpnSNeX794x22WYj9duSFTUxn
Re: Question to candidates: what are your quantitative diversity goals and metrics?
On Sat, Apr 06, 2024 at 12:14:01AM +0530, Sruthi Chandran wrote: >On 28/03/24 05:56, Roberto C. Sánchez wrote: > > Greetings candidates, > > QUESTION TO THE CANDIDATES: what are your quantitative diversity goals > and metrics, and what are the rationales behind those goals and metrics? > >Sorry, I do not wish to put a quantitative value to solve a social issue. > ... > > Again, these are merely examples. I am interested in how you define > diversity and what metrics and goals you derive from that definition. > >I believe there is no point in talking in % when more than 95% of people >are from one gender. > It seems counterintuitive that immediately after saying that you "do not wish to put a quantitative value to solve a social issue" you decided to put a quantitative value on a social issue as a way of saying "there is no point in talking in %". I suppose that once we reach a point as a project where *less* than 95% of people are from one gender then perhaps you will see a point to talking about this issue in quantitative terms and be willing to discuss. Regards, -Roberto -- Roberto C. Sánchez
Re: (last minute) Question to both candidates: CRA+PLD, similar regulations, and Debian
Hi Santiago, Am Fri, Apr 05, 2024 at 03:21:48PM -0300 schrieb santiago: > ... > Non-commercial FLOSS products/projects do not have to comply with CRA. > However, I think there could be an impact in the industry regarding the > adoption and use of Debian. > > What are you thoughts on the subject? > > Should Debian help those commercial downstreams to fulfill the > requirements? I would like to discuss this complex topic with people who are involved more deeply into this topic. I consider the current person-power within Debian insufficient for taking on additional tasks. Thus, even though we may have the intention to assist, the implementation remains challenging. I'm uncertain whether commercial downstreams might allocate resources towards legal expertise to find ways to adapt the law situation or explore alternative strategies to address this situation. Kind regards Andreas. > [CRA] https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.html > > Thanks for running for DPL to both of you! > > -- Santiago -- 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: (last minute) Question to both candidates: CRA+PLD, similar regulations, and Debian
On 05/04/24 23:51, santiago wrote: Dear DPL candidates, As you may be aware, the EU has adopted a new cybersecurity regulation [CRA] and other countries are following the example. You may also be aware that Debian issued a public statement about it (based on a previous draft version of the regulation) last year. CRA will have an impact on commercial Debian downstreams, specifically on all of those who are placing a Debian-inside product in the EU single market. Part of the requirements rely on data that should be found in every single package integrated by the commercial downstream. And, as of today, part of that data is non existing. E.g.: include (meta)data about the support status upstream (supported, non-supported version, EOS date, ..., required for Article 13 (11)). Also manufacturers are required to "apply effective and regular tests and reviews of the security of the product with digital elements" (Annex I pII (3)). Non-commercial FLOSS products/projects do not have to comply with CRA. However, I think there could be an impact in the industry regarding the adoption and use of Debian. What are you thoughts on the subject? Should Debian help those commercial downstreams to fulfill the requirements? Right now I do not have a lot of idea about CRA and its impact, but I would say what I think about downstream distros. Since in Debian, we do not want to discriminate between commercial and non-commercial adaptations, I do think that we should look into the issue and see if there is any way that Debian can help out. For this, we need to study in detail about CRA, may be take help from lawyers and explore possibilities. [CRA]https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.html Thanks for running for DPL to both of you! -- Santiago OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to candidates: Addressing Bandwidth Challenges in Debian
On 26/03/24 00:26, Nilesh Patra wrote: It is no secret that most (probably all?) teams (delegated and otherwise packaging/developer teams) in Debian struggle with limited developer time and almost everything in Debian needs help. In quite a few teams that I've seen and also been a part of, there are only 3-4 people sharing a bulk of workload, sometimes it is even worse and there are 1-person teams too -- teammetrics stats can shed some light on it[1]. I completely agree with you. We definitely have shortage of volunteers for different teams. This imbalance can lead to exhaustion, burnouts, et. al. and having a low bus factor also poses an issue for stale packages/development in the corresponding teams when the people doing a lot of work there become busy with RL and can't dedicate much time. Do you have any plans to address this or any strategies so the workload could be somewhat better managed making this sustainable? (I know outreach to get new people onboard is one option but I'm looking for more opinions/points here.) To be honest, I do not have any solid plan or strategy to deal with this issue. The lack of volunteers to take up tasks is not just an issue with Debian, but is common in other free software groups or any volunteer based groups. As a DPL, one thing I plan to do is review the delegated teams and talk to them to know if they are understaffed and/or overloaded and address the issue appropriately. Also, I would be interested to hear from Debianites if they have some interesting suggestions. Another thing I have in mind is to interact and learn from other free software/volunteer groups how they are coping up with this bandwidth issue. [1]:https://wiki.debian.org/Teammetrics/API PS: While this question is for DPL candidates, anyone is free to chime in. Best, Nilesh OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question to candidates: what are your quantitative diversity goals and metrics?
On 28/03/24 05:56, Roberto C. Sánchez wrote: Greetings candidates, QUESTION TO THE CANDIDATES: what are your quantitative diversity goals and metrics, and what are the rationales behind those goals and metrics? Sorry, I do not wish to put a quantitative value to solve a social issue. Some context: Both platforms cite imbalances in the areas of gender and geography as concerns contributing to each candidate's desire to serve as DPL. Andreas: "Currently, there is a notable over representation of male contributors originating from countries typically considered industrialized." Sruthi: "... more gender diverse people will feel comfortable joining our community. Geographic/ethnic diversity are also important areas which need attention." (I should note that Sruthi's platform dedicated considerably more space to the issue of diversity, but the particular statement I chose to quote seemed representative.) ... - Debian should represent the gender diversity of the whole world. The world population is split approximately 50/50 male and female (with a very slight bias towards more males) [1], with "transgender people and other gender minorities, who comprise an estimated 0.3–0.5% (25 million) of the global population" [2]. Using the above figure of 1004 DDs, a balanced Debian population could be 500 male DDs, 499 female DDs, and 5 DDs who identify as transgender or another gender minority. Based on this composition, it seems likely that Debian has adequate representation of transgender and gender minority DDs, so focusing efforts specifically on outreach to women would provide the greatest benefit towards achieving a balanced representation. Again, these are merely examples. I am interested in how you define diversity and what metrics and goals you derive from that definition. I believe there is no point in talking in % when more than 95% of people are from one gender. Regards, -Roberto [0]https://en.wikipedia.org/wiki/List_of_countries_by_population_(United_Nations) [1]https://en.wikipedia.org/wiki/Human_sex_ratio [2]https://web.archive.org/web/20220131080803/https://www.euro.who.int/en/health-topics/health-determinants/gender/gender-definitions/whoeurope-brief-transgender-health-in-the-context-of-icd-11 OpenPGP_signature.asc Description: OpenPGP digital signature
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: Q to Sruthi: technical goals and relevance of Debian
On 05/04/24 12:26, Lucas Nussbaum wrote: Hi Sruthi, In your platform and answers to questions here, I feel that you mainly focus on the "behind the scenes" aspects of Debian for the public, that is, how the project works. This is of course extremely important, but to put it bluntly, I believe that for Debian to be successful, it first needs to be good at what it produces (the distribution). Being a diverse and welcoming and generally well-functionning community is nice, but not very important if what we produce becomes irrelevant and nobody cares about Debian anymore. Do you agree? Yes, I do agree that we should be good or rather aim to be the best among the distros. Regarding what we produce, what do you perceive as the main challenges ahead? What are our main weaknesses to address them? What are the big threats that we will likely have to face in the next years? Are there opportunities we could leverage? Currently we have a good share of servers and systems running on Debian, but if we take newer devices like smartphones and embedded systems, we are far behind. I believe that we are reluctant to change and that is holding us back in exploring new horizons. In upcoming years, many of our current excellent projects will be obsolete and we may not be good enough in newer projects if we are reluctant to change. The biggest threat is the rate of change the technological world is going through - will we able to keep up with them? Of course, as the DPL, it is unlikely that you will find the time to work on those challenges yourself. But you will have many opportunities to draw attention to topics of importance (in interviews, talks, bits, etc.), or, when allocating ressources (e.g. Debian funds) to prioritize one topic or another. While I do agree that a DPL has some influence on drawing attention to certain topics, it is the project as a whole which should take up the challenge to change and stay relevant. Best, Lucas OpenPGP_signature.asc Description: OpenPGP digital signature
(last minute) Question to both candidates: CRA+PLD, similar regulations, and Debian
Dear DPL candidates, As you may be aware, the EU has adopted a new cybersecurity regulation [CRA] and other countries are following the example. You may also be aware that Debian issued a public statement about it (based on a previous draft version of the regulation) last year. CRA will have an impact on commercial Debian downstreams, specifically on all of those who are placing a Debian-inside product in the EU single market. Part of the requirements rely on data that should be found in every single package integrated by the commercial downstream. And, as of today, part of that data is non existing. E.g.: include (meta)data about the support status upstream (supported, non-supported version, EOS date, ..., required for Article 13 (11)). Also manufacturers are required to "apply effective and regular tests and reviews of the security of the product with digital elements" (Annex I pII (3)). Non-commercial FLOSS products/projects do not have to comply with CRA. However, I think there could be an impact in the industry regarding the adoption and use of Debian. What are you thoughts on the subject? Should Debian help those commercial downstreams to fulfill the requirements? [CRA] https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.html Thanks for running for DPL to both of you! -- Santiago signature.asc Description: PGP 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: Q to Andreas: weaknesses and challenges outside packaging?
On 05/04/24 at 14:24 +0200, Andreas Tille wrote: > Hi Lucas, > > Am Fri, Apr 05, 2024 at 08:56:42AM +0200 schrieb Lucas Nussbaum: > > Hi Andreas, > > > > In your platform and answers to questions here, I feel that you mainly > > focus on the visible side of Debian for the public, that is, the > > distribution we produce. > > > > However, the role of the DPL is a lot about working on fixing all the > > little annoyances that make it less fun for contributors to work on > > Debian. In my experience, that involves a lot of work with "behind the > > scenes" teams. > > > > What is your past experience is that area? > > None. > > > And looking ahead, what do you perceive as the main weaknesses of Debian > > in that area? What are our main challenges ahead? What are the big > > threats that we will likely have to face in the next years? Are there > > opportunities we could leverage? > > These are exactly the questions I would have to you (and other previous > DPLs) in case I might become elected. Heh, note that in my case, I'm mostly out of date about the internal state of Debian. For example, I have absolutely no idea about the current health of our core teams. And it's likely (I hope!) that the problems we were struggling with 10 years ago are not the ones we are facing currently. Lucas
Re: Q to Andreas: weaknesses and challenges outside packaging?
Hi Lucas, Am Fri, Apr 05, 2024 at 08:56:42AM +0200 schrieb Lucas Nussbaum: > Hi Andreas, > > In your platform and answers to questions here, I feel that you mainly > focus on the visible side of Debian for the public, that is, the > distribution we produce. > > However, the role of the DPL is a lot about working on fixing all the > little annoyances that make it less fun for contributors to work on > Debian. In my experience, that involves a lot of work with "behind the > scenes" teams. > > What is your past experience is that area? None. > And looking ahead, what do you perceive as the main weaknesses of Debian > in that area? What are our main challenges ahead? What are the big > threats that we will likely have to face in the next years? Are there > opportunities we could leverage? These are exactly the questions I would have to you (and other previous DPLs) in case I might become elected. I might realise that I'm absolutely naive about the options I have to change what you call the visible side and get swamped by the things you are mentioning. I tried to address your questions in my platform "What makes me afraid about running for DPL". I received some hints from previous DPLs and I trust I can rely on your past experiences. Kind regards Andreas. -- 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
