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 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 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 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 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 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
