Q to Andreas: weaknesses and challenges outside packaging?
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? 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? Best, Lucas signature.asc Description: PGP signature
Q to Sruthi: technical goals and relevance of Debian
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? 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? 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. Best, Lucas signature.asc Description: PGP signature
Draft ballot
Here is the draft ballot:
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
14hTUYuuvc0MeWSVpnSNeX794x22WYj9duSFTUxn2xcyZXbWxhNWTzD+8ZlQKd+H
AEFM7KSCaet2WfhM
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 gets
