Re: Question to all candidates: What are your technical goals
Hi, now that the campaign period has ended, I will write my longer answer on -devel where it belongs. On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber: > > I think this can't just be seen by looking at the statistiks. Many small > > packages do their job and don't need constant attention as long as they > > still build and work. > > I agree that pure statistics is not telling the whole story. However, > those statistics give some feeling about the issue which for sure needs > to be verified on case-by-case basis. I can assure you that I usually > inspect the list of smelly packages[1] whether there are hits for my > name (currently one false positive and one package where I'm forced to > use cdbs) but also look for packages I might be able to salvage from > there. I've found some impressive hits for this purpose in the past > that are supporting my point besides stupid statistics. > -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 10:14:59AM -0700 schrieb Soren Stoutner: > On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote: > >[ ] Its not acceptable, don't do that > >[ ] We should discuss this on debian-devel, possibly do some GR > >before things like this are permitted > >[ ] Wait one week before uploading > >[X] Wait one day before uploading > >[ ] Just upload provided you care for any break your action might > >have caused. > >[ ] ??? > > Given the circumstances, I think waiting one day before uploading is > appropriate. > > I also feel that asking this question on this list is appropriate. It is > insightful in helping me understand how Andreas would approach being the DPL, > thus informing my vote. Summarising my question about how to deal with an example RC bug that affects some dependency tree of some team: 1. Prefer NMU which solves the problem quickly. I do not volunteer to do this since I do not consider it sustainable in the said situation. 2. Prefer package salvaging (which I did now #1068561 but its a lengthy process that will trigger another series of testing removal warnings in between) 3. Two responses would agree to an alternative way which are not backed up by any procedure we agreed upon so I will not do this. I wonder whether we can use this as some input to simplify / shorten the salvage process or whether we should move on as before. Additional remark: When reading the PackageSalvaging FAQ[1] I realised that my way to talk about examples might be considered finger pointing no matter whether I write that this is not intended. I understand I was wrong here and I'm sorry about doing so. I do not intend to do this in future any more. Kind regards Andreas. [1] https://wiki.debian.org/PackageSalvaging#FAQs -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi again, Am Sat, Apr 06, 2024 at 09:26:25AM +0200 schrieb Tobias Frost: > > I want to be able to immediately respond to future problems in this > > package. I'm fine with putting Debian Med team as maintainer, but not > > my personal ID (maximum as Uploader since I do not have any personal > > packages). > > > > Do you think this would be the appropriate action (which I personally > > would even prefer over debian/ space)? The conservative criteria > > are fulfilled. > > Yes, (if your name is in Uploaders:) this is is fine. I've filed ITS bug #1068561. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Fri, Apr 05, 2024 at 12:37:19PM +0200, Andreas Tille wrote: > Hi Tobias, > > Am Thu, Apr 04, 2024 at 07:59:56PM +0200 schrieb Tobias Frost: > > > > There is the possilbity to salavage the packagei [1], but that of course > > will > > only work if the person agrees to take over maintainance and add their name > > to > > Uploaders: or Maintainer: [2]. > > I want to be able to immediately respond to future problems in this > package. I'm fine with putting Debian Med team as maintainer, but not > my personal ID (maximum as Uploader since I do not have any personal > packages). > > Do you think this would be the appropriate action (which I personally > would even prefer over debian/ space)? The conservative criteria > are fulfilled. Yes, (if your name is in Uploaders:) this is is fine. > Kind regards >Andreas. > > > The package can be put into a team's umbrella at the ITS time. This > > does not need an explicit OK, though the maintainer can veto. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > https://wiki.debian.org/PackageSalvaging > > > > [2] This is a feature, the ITS procedure has been designed exactly that > > way, to avoid that people just do an upload and drop the package > > immediatly afterwards, as this will likely only upset the current > > maintainer without long-term benefits to the package - kind of to > > avoid the reaction Marc predicted. > > If taking over the maintaince is not the goal, remember NMU allow > > one to fix almost every bug, also wishlist bugs are regularily in > > scope. And bugs can be filed, if needed. > > Some Background story: > > https://lists.debian.org/debian-devel/2018/07/msg00453.html > > > > -- > > tobi > > > > -- > https://fam-tille.de > signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Holger, Am Fri, Apr 05, 2024 at 10:42:35AM + schrieb Holger Levsen: > On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > > also: (NMU-)uploads to DELAYED/15 are great. > > Sorry, I do not feel my time well spent on just curing a symptom > > (unfixed RC bug) via NMU instead of addressing the underlying cause > > that the package is maintained by a single person. > > so you value your values and needs higher than our shared and agreed values. I do not think that we agreed upon how volunteers might spent their time. There is a patch in BTS for the said bug and I take the freedom to not NMU. At the time of writing it seems every other developer prefers to do other things than uploading the patch. No idea how you conclude from this fact to some values I'm weighting differently. What I want to find out is: Are the values we agreed upon meeting todays needs or not? Is the developer community interested in some change I might start or not? Please take this discussion as my way to find some pain points in the discussion to act more sensibly on debian-devel once we might talk about new ways. > noted. > > (also, pressuring people to accept more co-maintainers can have serious > side effects as became very visible last weekend with xz upstream...) Seems that case makes a great argument which is pretty popular these days. I'd love to have some explanation in how far it matches the example I gave. I have no means to pressure anybody - neither to make a maintainer accept contributions nor any co-maintainer to provide any contribution. My point is to enable better chances for cooperation between people we trust anyway. > Make facts great again. Yeah! Kind regards Andreas. -- https://fam-tille.de
Re: Question to all candidates: 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: 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
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli wrote: > > > In practical terms, it would probably be made easier if it was > > mandatory for all packages to be on Salsa, either in the 'debian' > > namespace or in a team namespace (but not under individual users). > > Realistically, even if you decide "everything is now team maintained", if > there is only 1 person who cares about a certain package there won't be any > team member doing anything about it. So having it on salsa or whatever won't > really do much, besides being annoying for people who have to change their > workflow for no reason. Sure, but this is in the context of project-wide changes discussed above. > Also let's not forget that it is expected for people who are not DD to > contribute to debian, and they can only create repositories on salsa under > their own name (for good reason, mostly). Such contributors need a DD sponsor, which means access can be granted to individual repositories.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Andreas, On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > Hi, > > in the light of the previous discussion I have a question to all voters. > Due to bug #1066377 more than 30 testing removal warnings hit my mailbox > today (I stopped counting after 30). While the Debian Med package > clustalo is the only package that's responsible for this due to its > Build-Dependency from libargtable2-dev there is quite some dependency > tree inside Debian Med team also affecting packages relevant for > COVID-19 etc. This small lib is not a key package which is important > for all things I'm writing below. Its used as Build-Depends by 6 other > packages. > > Our always busy team member Étienne Mollier provided a patch 10 days ago > (thanks again Étienne). The package had its last maintainer Upload > > -- Shachar Shemesh Sat, 16 Jul 2016 20:45:15 +0300 > > (Shachar in CC) and a NMU > > -- Holger Levsen Fri, 01 Jan 2021 17:15:04 +0100 > > (reproducible build, no changes - in other words no problems since > 2016). However, the BTS view of Sanchar might hinting for some > inactivity when looking at two RC bugs in other packages: > > #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm > #998987 [src:privbind] privbind: missing required debian/rules targets > build-arch and/or build-indep > > As I wrote to Marc here on this list also the explicit hint to Shachar: > Its not about blaming you - I just want to analyse the current situation > to act properly. Given that you had no capacity to respond to two bugs > that are RC since 2 years makes me wonder how long I need to wait for > your OK to a team upload I'm proposing below. I'm perfectly aware that > we as volunteers can't be blamed about those things. I simply want to > find new ways how to deal with those situations appropriately. There is the possilbity to salavage the packagei [1], but that of course will only work if the person agrees to take over maintainance and add their name to Uploaders: or Maintainer: [2]. The package can be put into a team's umbrella at the ITS time. This does not need an explicit OK, though the maintainer can veto. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging https://wiki.debian.org/PackageSalvaging [2] This is a feature, the ITS procedure has been designed exactly that way, to avoid that people just do an upload and drop the package immediatly afterwards, as this will likely only upset the current maintainer without long-term benefits to the package - kind of to avoid the reaction Marc predicted. If taking over the maintaince is not the goal, remember NMU allow one to fix almost every bug, also wishlist bugs are regularily in scope. And bugs can be filed, if needed. Some Background story: https://lists.debian.org/debian-devel/2018/07/msg00453.html -- tobi signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote: >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[X] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? Given the circumstances, I think waiting one day before uploading is appropriate. I also feel that asking this question on this list is appropriate. It is insightful in helping me understand how Andreas would approach being the DPL, thus informing my vote. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Am Thu, Apr 04, 2024 at 01:04:49PM + schrieb Holger Levsen: > On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > > I would like to learn what options I have to realise paragraph > >Packaging standards > > of my platform. > > I also think this feels a bit like abusing the election audience for a > topic Fair enough. I personally have seen the campaigning period as a way voters might learn how I intend to work. You can take my message also as my style of leadership to ask in advance to get some picture. > which should be discussed on -devel outside campaigning. I confirm debian-devel is the right place to discuss this issue in detail and for sure I would move (or better reopen) the discussion there. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[X] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? For a younger RC bug, use a longer waiting period. But here things are clear that nothing would happen in a week. And, of course, anyway, care for any break you have caused. As a maintainer, seeing my package break after an NMU, I would sit tight and silent for a few days and wait for the NMUer to fix their damage. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 13:40, Andreas Tille wrote: > > Hi Luca, > > Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > > > That's the price we currently pay for being not a commercial entity, > > > > > > I fully subscribe to this statement. > > > > I don't think commercial entities have anything to do with this. > > Fedora is not a commercial entity (please, no FUD about RH) and yet it > > can take decisions and implement them just fine. It's entirely a > > question of self-organization and what rules we decide for the > > project. > > Please don't get me wrong: I do not consider Fedora a commercial > entity. I simply subscribe the statement that we are facing some > problems in Debian since we are not a commercial entity. I think the framing is slightly misleading: it's true that a commercial entity with a hierarchical structure would not have the same issue, but the point I am making is that there's nothing stopping a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora. Hence, it's not just the fact that Debian is not a commercial entity that leads to the status quo, but the combination of not being a commercial entity _plus_ precise and explicit choices about project governance. > > > I need to admit that I (currently) don't know much about Fedora (but I > > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > > took the chance to talk to OpenSUSE and Nix about organisatorical > > > solutions. There was no booth by Fedora I could show up. > > > > In short, Fedora project members elect a technical committee, FESCO. > > Project members can submit proposals to this committee for > > project-wide changes, which votes on whether to approve them or reject > > them. If they are approved, the committee and the proposer are > > empowered to enact the changes distro-wide - whether individual > > package maintainers like them or not. An approved proposal can fail > > and be rolled back for technical reasons (e.g.: unexpected issues crop > > up at implementation time), but not because random package maintainers > > practice obstructionism because they don't like the decision. > > If you compare this to Debian what exactly is your proposal to change > for the better? For starters there needs to be a decision on whether the status quo is fine or change is needed. That is non-obvious, I have my opinion but others will have theirs. It would mean the end of "my package is my fiefdom", and a move towards collective maintenance. >From the organizational point of view, it would require a GR to change in the constitution to enshrine the power to take technical decisions and make them happen into a constitutional body - the CTTE will probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't want it. A procedure to submit proposals for discussion with the whole project should be established (we already have the DEP process for example), that ends with a vote of the decision makers body. And once the body makes a technical strategy decision, them or whoever they want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and discuss is _before_ the decision is made, not _after_. In Fedora every proposal must include a criteria to allow declaring that the game's a bogey and plan to rollback, in case something goes wrong, but this is again decided by the decision makers body. In practical terms, it would probably be made easier if it was mandatory for all packages to be on Salsa, either in the 'debian' namespace or in a team namespace (but not under individual users). Then perhaps for each approved decision, until the project is completed the implementer(s) would automatically get write access to all teams namespaces to push the changes - as MRs because reviews are good, but with the powers to merge them too. I'm getting ahead of myself, but hopefully you get the idea.
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On April 4, 2024 12:59:34 PM UTC, Andreas Tille wrote: >Hi Scott, > >Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman: >> I'm interested to understand what you think this has to do with the DPL >> election or the role of the DPL within the project? > >I would like to learn what options I have to realise paragraph > > Packaging standards > >of my platform. Thanks. Obviously the DPL has an outsized voice in Debian. When the DPL says something, it will tend to get more attention within the project. Beyond that, what specific powers of the DPL will help you realize this goal? In other words, why do you need to be DPL to do this? Scott K
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > I would like to learn what options I have to realise paragraph >Packaging standards > of my platform. I also think this feels a bit like abusing the election audience for a topic which should be discussed on -devel outside campaigning. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi Scott, Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman: > I'm interested to understand what you think this has to do with the DPL > election or the role of the DPL within the project? I would like to learn what options I have to realise paragraph Packaging standards of my platform. Kind regards Andreas. -- https://fam-tille.de
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On April 4, 2024 12:32:45 PM UTC, Andreas Tille wrote: >Hi, > >in the light of the previous discussion I have a question to all voters. >Due to bug #1066377 more than 30 testing removal warnings hit my mailbox >today (I stopped counting after 30). While the Debian Med package >clustalo is the only package that's responsible for this due to its >Build-Dependency from libargtable2-dev there is quite some dependency >tree inside Debian Med team also affecting packages relevant for >COVID-19 etc. This small lib is not a key package which is important >for all things I'm writing below. Its used as Build-Depends by 6 other >packages. ... > >What do you think? > Andreas, I'm interested to understand what you think this has to do with the DPL election or the role of the DPL within the project? Scott K
Re: Question to all candidates: What are your technical goals
Hi Luca, Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > As far as I know other major distributions do not undertake the time_t > > 64bit transition (whether this marks leadership or not is questionable > > but it will make us the leading distribution on those architectures in > > future). > > Of course they are, most of the important work lately has been done by > SUSE for example, to replace legacy components that will hopelessly > break in 2038. Of course they have an advantage in not having to carry > around dead architectures, so it's easier. Thank you for the information. > > I think we are doing a good job regarding CI with adding autopkgtests > > (but we could do even better for sure). I'm not informed about the > > status of CI in other distributions and whether there exists something > > like Salsa CI. I'm positively convinced that Debian has reached a level > > of complexity which makes CI tests mandatory for every important package > > and I would love if we could do the lead here. > > OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's > source control system has a CI integrated with it that is similar to > the one we have. Packit is even starting to make its way in upstream > projects's CIs, we use it in systemd for example, so that upstream PRs > also build and test Fedora packages in Fedora images. We do the same > with Debian and autopkgtest btw. Thanks again. As I admitted in my platform I'm not well informed about other distributions but I'm willing to become better informed to be able to learn from others. > > > That's the price we currently pay for being not a commercial entity, > > > > I fully subscribe to this statement. > > I don't think commercial entities have anything to do with this. > Fedora is not a commercial entity (please, no FUD about RH) and yet it > can take decisions and implement them just fine. It's entirely a > question of self-organization and what rules we decide for the > project. Please don't get me wrong: I do not consider Fedora a commercial entity. I simply subscribe the statement that we are facing some problems in Debian since we are not a commercial entity. > > I need to admit that I (currently) don't know much about Fedora (but I > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > took the chance to talk to OpenSUSE and Nix about organisatorical > > solutions. There was no booth by Fedora I could show up. > > In short, Fedora project members elect a technical committee, FESCO. > Project members can submit proposals to this committee for > project-wide changes, which votes on whether to approve them or reject > them. If they are approved, the committee and the proposer are > empowered to enact the changes distro-wide - whether individual > package maintainers like them or not. An approved proposal can fail > and be rolled back for technical reasons (e.g.: unexpected issues crop > up at implementation time), but not because random package maintainers > practice obstructionism because they don't like the decision. If you compare this to Debian what exactly is your proposal to change for the better? Kind regards Andreas. -- https://fam-tille.de
Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
Hi, in the light of the previous discussion I have a question to all voters. Due to bug #1066377 more than 30 testing removal warnings hit my mailbox today (I stopped counting after 30). While the Debian Med package clustalo is the only package that's responsible for this due to its Build-Dependency from libargtable2-dev there is quite some dependency tree inside Debian Med team also affecting packages relevant for COVID-19 etc. This small lib is not a key package which is important for all things I'm writing below. Its used as Build-Depends by 6 other packages. Our always busy team member Étienne Mollier provided a patch 10 days ago (thanks again Étienne). The package had its last maintainer Upload -- Shachar Shemesh Sat, 16 Jul 2016 20:45:15 +0300 (Shachar in CC) and a NMU -- Holger Levsen Fri, 01 Jan 2021 17:15:04 +0100 (reproducible build, no changes - in other words no problems since 2016). However, the BTS view of Sanchar might hinting for some inactivity when looking at two RC bugs in other packages: #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm #998987 [src:privbind] privbind: missing required debian/rules targets build-arch and/or build-indep As I wrote to Marc here on this list also the explicit hint to Shachar: Its not about blaming you - I just want to analyse the current situation to act properly. Given that you had no capacity to respond to two bugs that are RC since 2 years makes me wonder how long I need to wait for your OK to a team upload I'm proposing below. I'm perfectly aware that we as volunteers can't be blamed about those things. I simply want to find new ways how to deal with those situations appropriately. Am Thu, Apr 04, 2024 at 12:38:34PM +0200 schrieb Andreas Tille: > > > > > > A. Packages should be maintained on Salsa > > > B. Lets use dh (if possible - I was told there are exceptions) > > > C. Commit to latest packaging standards > > > D. Make more than one person responsible for a package > > > E. General QA work of contributors not mentioned as Maintainer / > > > Uploader > > > > > > > > > 1. Fix vcs_url + vcs_browser (A.) I moved the package to salsa[1] and added VCS fields > > > 2. Fix some bug(s) (E.) I applied the patch from Étienne. > > > 3. Runs Janitor / routine-update which changes (C.) I was running `routine-update -f` > > > 4. Converts to dh (if not yet which I did not checked) (B.) I removed debian/autoreconf.* files which were unneeded with latest dh compat level (and routine-update is doing this). > > > 5. Turn d/copyright into machine readable form (if not yet which > > > I did not checked) (C.) Secure URI in copyright format > > > 6. Finds a team where the package fits into moves the repository > > > to that team space and moves you to Uploaders (D.) I simply sticked to debian/ since I have no idea what team might fit. > I forgot > 7. Add autopkgtest I admit I did not spent time into this. > > 1-5 are just fine. That's what git is for. Either fork the project, > > commit changes, file an MR, or (dor a repository inside the Debian/ > > space), commit to a branch, file an MR. > > Thank you for your opinion. It is very valuable for me to learn what > people consider acceptable. I assume you would consider 7. fine as > well. I guess this is fulfilled. > > Personally, I do prefer having the last word to say what gets into > > the master/main branch and I'd like to at least be consulted before an > > upload. > > If no team is specified this is definitely default behaviour. Shachar is in CC of this mail. > > I might look like a rotten maintainer when you look at my oldest > > packages, > > Absolutely not. When digging into the said resources I have seen way > worse. I'm not here to blame anybody. I'm seeking for solutions. Sorry again for just picking this example which is attached to you (Shachar). I neither wanted to blame Marc about anything in my previous mail nor you in this mail. Its simply the kind of thing that is creating a lot of stress in our team. I could follow the normal NMU procedure but I do not consider this a sustainable solution. It took me about 10-15 min in my lunch break to bring the package into a shape, where other people are able to commit in a convenient way (Salsa, latest packaging standards). > > 6 I would find too intrusive without talking to me first. It's a slap in > > the face, I would probably drop the package as a kneejerk reaction. > > Talking to you is mandatory. I know you for a long time as helpful and > responsive on mailing lists. But assume we are talking about someone > who does not respond (for whatever reason). Could you imagine some > scenario where 6. would be acceptable? I did not uploaded my work but I would like to know what action is considered acceptable by the voters. I repeat that the package is no key package for which I would not consider what I did above. Please simply
Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 11:39, Andreas Tille wrote: > > Hi Marc, > > Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber: > > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote: > > "we now use Wayland > > instead of X11", "please don't create your system users with adduser and > > more, use a declarative approach". > > > > At the moment, we simply dont take such decisions. I think that's a > > problem. > > I think I get your point now. Thanks for these examples. You might > have a point in these specific ones but I see Debian leading in other > aspects. > > As far as I know other major distributions do not undertake the time_t > 64bit transition (whether this marks leadership or not is questionable > but it will make us the leading distribution on those architectures in > future). Of course they are, most of the important work lately has been done by SUSE for example, to replace legacy components that will hopelessly break in 2038. Of course they have an advantage in not having to carry around dead architectures, so it's easier. > I'm not well informed about other distributions but seeked the internet > and for instance found some article about reproducible builds from > 2019[2] where Debian and ArchLinux are mentioned frequently but Fedora > is not. I've picked that older article since taking the lead means who > started that effort and I think we are in this game. > > Apropos ArchLinux: I would love if Debian would manage to craft such a > great documentation in Wiki. That's not a "technological" lead but > we've lost the lead in documentation by far which is in my perception a > weaker point than the time we adopt one or the other technical change. > > I think we are doing a good job regarding CI with adding autopkgtests > (but we could do even better for sure). I'm not informed about the > status of CI in other distributions and whether there exists something > like Salsa CI. I'm positively convinced that Debian has reached a level > of complexity which makes CI tests mandatory for every important package > and I would love if we could do the lead here. OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's source control system has a CI integrated with it that is similar to the one we have. Packit is even starting to make its way in upstream projects's CIs, we use it in systemd for example, so that upstream PRs also build and test Fedora packages in Fedora images. We do the same with Debian and autopkgtest btw. > > > > Are our technical > > > > decision-making processes up to today's challenges? > > > > > > Would you mind clarifying this question? We have the CTTE as > > > decision-making instance but I'm not sure whether you are refering to > > > this. > > > > The CTTE is a tie-breaker which is only invoked to resolve a fight. And > > if invoked, the decision takes months. In other sitations, we keep > > fighting in the open, probably doing a GR, which makes the news even > > before we have decided anything. > > > > That's the price we currently pay for being not a commercial entity, > > I fully subscribe to this statement. I don't think commercial entities have anything to do with this. Fedora is not a commercial entity (please, no FUD about RH) and yet it can take decisions and implement them just fine. It's entirely a question of self-organization and what rules we decide for the project. > > so > > that we don't have a project leader who has the power to say "we're > > going to do X", like the board or the managing director of a commercial > > company has. > > I consider the DPL as a "Leader with no power". Convincing a huge > number of volunteers to pull a string into the same direction is a way > harder job than telling employees of a company what to do next. I'm > aware of this challenge. > > > Seriously, I don't how Fedora takes their technical > > decision, but there has to be a reason why they're so far ahead of us > > technologically. > > I need to admit that I (currently) don't know much about Fedora (but I > hope I could fix this in the near future). At Chemnitzer Linuxtage I > took the chance to talk to OpenSUSE and Nix about organisatorical > solutions. There was no booth by Fedora I could show up. In short, Fedora project members elect a technical committee, FESCO. Project members can submit proposals to this committee for project-wide changes, which votes on whether to approve them or reject them. If they are approved, the committee and the proposer are empowered to enact the changes distro-wide - whether individual package maintainers like them or not. An approved proposal can fail and be rolled back for technical reasons (e.g.: unexpected issues crop up at implementation time), but not because random package maintainers practice obstructionism because they don't like the decision.
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > I see a big problem that we do not follow common standards. While we
> > have some teams with strict policies setting those standards internally
> > to a different level of strictness there is no Debian wide consensus
> > about things like
> >
> > A. Packages should be maintained on Salsa
> > B. Lets use dh (if possible - I was told there are exceptions)
> > C. Commit to latest packaging standards
> > D. Make more than one person responsible for a package
> > E. General QA work of contributors not mentioned as Maintainer /
> > Uploader
> >
> > [I will reference these items below by their letters]
> >
> > I'm addressing this in the paragraph "Packaging standards" of my
> > platform. I'm also very concerned about packages who don't get
> > any attention any more ("smelly packages") which has two major
> > reasons:
> >
> > 1. We do not have contributors with free capacity to care for
> > problems in other peoples packages
> > 2. Even if we had those the strict ownership of packages pevents
> > that new contributors can step in. When reading the paragraph
> > about NMUs in developers reference[1] this is probably
> > sensible for actively maintained packages - but what about
> > those packages which do not show any activity for years?
>
> I think this can't just be seen by looking at the statistiks. Many small
> packages do their job and don't need constant attention as long as they
> still build and work.
I agree that pure statistics is not telling the whole story. However,
those statistics give some feeling about the issue which for sure needs
to be verified on case-by-case basis. I can assure you that I usually
inspect the list of smelly packages[1] whether there are hits for my
name (currently one false positive and one package where I'm forced to
use cdbs) but also look for packages I might be able to salvage from
there. I've found some impressive hits for this purpose in the past
that are supporting my point besides stupid statistics.
> ...
> Those three packages I decided not to put work into until there is a
> technical reason for doing so. I do have all three on the radar and they
> will properly move to salsa and be modernized once there will be a
> change to the code or an RC bug regarding packaging. Until then, I have
> more important things to do.
Thanks for going into detail about these which I neither wanted nor
expected in this granularity. I had no doubt that there are more
important things for you. I honestly tried to investigate by using
these examples is the following: In case there might be people out
there who have time and energy to fix this kind of things, how can we
enable them to take this work from your shoulders to enable you
concentrating on more important stuff.
> policyrcd-script-zg2 I should modernize and upload. A few people seem to
> actually use this, and it helps getting rid of the discussions whether a
> distributio should start a daemon right after package installation
> (which we do, and Red Hat based distributions don't, causing irritations
> by people accustomed to Red Hat working with Debian). You got a point
> here.
As I said I did not wanted to make a point about your maintainership.
I simply wanted to discuss existing examples instead of statistics.
> Those bugs are either wontfix, or already fixed in git (not yet uploaded
> because cosmetic), or neglected, right.
I personally tend to upload when I've fixed some bug in Git (even when
cosmetic) to remove noise from BTS. In the said cases it would
specifically helpful to fix VCS information since it is very important
information for other Debian contributors. Before uploading I usually
run `routine-update -f` which is just upgrading to latest standards by
calling Janitor tools and does some other changes to keep up with latest
packaging standards semi-automatically.
> > What would you think if someone would push the following
> > commits and uploads to unstable:
> >
> > 1. Fix vcs_url + vcs_browser (A.)
> > 2. Fix some bug(s) (E.)
> > 3. Runs Janitor / routine-update which changes (C.)
> > 4. Converts to dh (if not yet which I did not checked) (B.)
> > 5. Turn d/copyright into machine readable form (if not yet which
> > I did not checked) (C.)
> > 6. Finds a team where the package fits into moves the repository
> > to that team space and moves you to Uploaders (D.)
I forgot
7. Add autopkgtest
> 1-5 are just fine. That's what git is for. Either fork the project,
> commit changes, file an MR, or (dor a repository inside the Debian/
> space), commit to a branch, file an MR.
Thank you for your opinion. It is very valuable for me to learn what
people consider acceptable. I assume you would consider 7. fine as
well.
> Personally, I do prefer having the last word to say what
Re: Question to all candidates: What are your technical goals
[snipped everything that I don't have an answer for. Neither removal nor
quoting is endorsement or reject of what Andreas said.]
On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> > There are many people who see Debian as a technology project, with the
> > technical goal of producing The Universal Operating System.
> >
> > What are you planning to do to Debian from a technical and technological
> > point of view? What do we well, where do we suck on the technical site?
>
> I see a big problem that we do not follow common standards. While we
> have some teams with strict policies setting those standards internally
> to a different level of strictness there is no Debian wide consensus
> about things like
>
> A. Packages should be maintained on Salsa
> B. Lets use dh (if possible - I was told there are exceptions)
> C. Commit to latest packaging standards
> D. Make more than one person responsible for a package
> E. General QA work of contributors not mentioned as Maintainer /
> Uploader
>
> [I will reference these items below by their letters]
>
> I'm addressing this in the paragraph "Packaging standards" of my
> platform. I'm also very concerned about packages who don't get
> any attention any more ("smelly packages") which has two major
> reasons:
>
> 1. We do not have contributors with free capacity to care for
> problems in other peoples packages
> 2. Even if we had those the strict ownership of packages pevents
> that new contributors can step in. When reading the paragraph
> about NMUs in developers reference[1] this is probably
> sensible for actively maintained packages - but what about
> those packages which do not show any activity for years?
I think this can't just be seen by looking at the statistiks. Many small
packages do their job and don't need constant attention as long as they
still build and work.
> I notived you are maintaining
>
> select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
> vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
> '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like
> '%salsa%') tmp;
> 20
>
> packages on Salsa in various teams. Great! You also have
>
> udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
> WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
> '%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
> source| maintainer |
> uploaders | vcs_browser
>
> --+--+---+--
> apg | Marc Haber |
>| http://git.debian.org/?p=collab-maint/apg.git;a=summary
> console-log | Marc Haber |
>| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
> dnstop | Marc Haber |
>| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
> policyrcd-script-zg2 | Marc Haber |
>| http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
> (4 rows)
>
> I verified on Salsa that all those are imported to debian/ name space on
> Salsa (which is also great - I have seen lots of other packages who are
> not imported to Salsa). It would help if you could sooner or later
> consider uploading those packages.
apg has a dead upstream and will probably have to go. Two years ago, I
decided to move the package to salsa to have it available for reference.
In parallel, I queried the maintainer of the least dead github fork
whether they are planning to take care of the upstream, received no
answer. The only commits that are not in the package are of cosmetic
value and I do not much believe in doing an upload (wasting buildd
resources, mirror bandwidth etc) just for the sake of those cosmetics.
console-log is little more than an init script that needs serious
rewriting to be usable on a systemd system. Probably also a candidate
for removal. I was not aware that Jelmer put the sources on salsa, I
appreciate their efforts.
dnstop I should probably either put up for adoption or have removed as
well. It hasn't seen a release in a decade, the last commit upstream was
two years ago, and I am not running DNS server at scale any more. Also,
I was not aware that the repository was put on salsa by Jelmer, probably
we shold have a mechanism to keep the maintainer of the Debian package
posted when something like that happens.
Those three packages I decided not to put work into until there is a
technical reason for doing so. I do have all three on the radar and they
will properly move to salsa and be modernized once there will be a
change to the code or an RC bug regarding
Re: Question to all candidates: What are your technical goals
Hi Marc,
Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> There are many people who see Debian as a technology project, with the
> technical goal of producing The Universal Operating System.
>
> What are you planning to do to Debian from a technical and technological
> point of view? What do we well, where do we suck on the technical site?
I see a big problem that we do not follow common standards. While we
have some teams with strict policies setting those standards internally
to a different level of strictness there is no Debian wide consensus
about things like
A. Packages should be maintained on Salsa
B. Lets use dh (if possible - I was told there are exceptions)
C. Commit to latest packaging standards
D. Make more than one person responsible for a package
E. General QA work of contributors not mentioned as Maintainer /
Uploader
[I will reference these items below by their letters]
I'm addressing this in the paragraph "Packaging standards" of my
platform. I'm also very concerned about packages who don't get
any attention any more ("smelly packages") which has two major
reasons:
1. We do not have contributors with free capacity to care for
problems in other peoples packages
2. Even if we had those the strict ownership of packages pevents
that new contributors can step in. When reading the paragraph
about NMUs in developers reference[1] this is probably
sensible for actively maintained packages - but what about
those packages which do not show any activity for years?
> If we do suck in some technical points, what are you planning to do to
> improve those things?
I would love to see that maintaining packages on Salsa becomes mandatory
and I wonder what might be the best way to approach this. We might
start with some GR about it. But perhaps it is better to start talking
to people. I use UDD as my reference and since I want to hear your
personal opinon I'm just querying for your packages. Its definitely not
about you personally - just a nice example.
I notived you are maintaining
select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
'%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like '%salsa%')
tmp;
20
packages on Salsa in various teams. Great! You also have
udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
'%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
source| maintainer |
uploaders | vcs_browser
--+--+---+--
apg | Marc Haber |
| http://git.debian.org/?p=collab-maint/apg.git;a=summary
console-log | Marc Haber |
| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
dnstop | Marc Haber |
| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
policyrcd-script-zg2 | Marc Haber |
| http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
(4 rows)
I verified on Salsa that all those are imported to debian/ name space on
Salsa (which is also great - I have seen lots of other packages who are
not imported to Salsa). It would help if you could sooner or later
consider uploading those packages. When seeking for other reasons I've
found 11 bugs via
udd=> SELECT id, package, source, arrival, severity, title FROM bugs WHERE
source IN (SELECT DISTINCT source FROM sources WHERE release = 'sid' and
(maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND
vcs_url not like '%salsa%');
which I will not list here to not lengthen this mail. My guess is you
are aware of this but have reasons / time constraints to not act for the
moment. What would you think if someone would push the following
commits and uploads to unstable:
1. Fix vcs_url + vcs_browser (A.)
2. Fix some bug(s) (E.)
3. Runs Janitor / routine-update which changes (C.)
4. Converts to dh (if not yet which I did not checked) (B.)
5. Turn d/copyright into machine readable form (if not yet which
I did not checked) (C.)
6. Finds a team where the package fits into moves the repository
to that team space and moves you to Uploaders (D.)
Assume you will be asked about those changes but you have no time
to answer (for whatever reason). What of those changes is OK for
you and how long would you expect the potential contributor to your
packages to wait until taking action?
> What is your position about technical leadership?
IMHO we could gain/keep technical leadership if we would manage to apply
our technical standards to all the things
Question to all candidates: What are your technical goals
Dear Candidates, There are many people who see Debian as a technology project, with the technical goal of producing The Universal Operating System. What are you planning to do to Debian from a technical and technological point of view? What do we well, where do we suck on the technical site? If we do suck in some technical points, what are you planning to do to improve those things? What is your position about technical leadership? Are our technical decision-making processes up to today's challenges? Thanks for your consideration to answer these questions despite platforms containing language about this topic. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
