Re: Bug#1053165: ITS: nunit
On September 29, 2023 10:01:45 AM UTC, Adam Borowski wrote: >On Thu, Sep 28, 2023 at 03:45:14PM +, Scott Kitterman wrote: >> On September 28, 2023 3:22:20 PM UTC, Bastian Germann >> wrote: >> >Okay. What do you suggest for "team maintained" packages where there is >> >no active team member? File MIA processes for each of the uploaders? >> >And then? The MIA team's bugs are not RC bugs, so you cannot even NMU >> >them based on the MIA bug. >> > >> >I think, just letting such packages rot for one or two decades does not >> > help anybody, certainly not our users. >> Any team member can orphan the package. > >A team with 99 MIA members one active is not the problem here. >But we have oh so many packages where the whole team is gone. > I agree. That's a different situation. Personally, it doesn't bother me if someone just uploads such packages with QA as the maintainer directly without bothering with the ITS process. If someone makes a mistake it's trivially reversible with a new upload and unlike a salvaged package there's no need to balance the equities of old/new maintainers. There's probably no rule that says that's okay though. Scott K
Re: Bug#1053165: ITS: nunit
On Thu, Sep 28, 2023 at 03:45:14PM +, Scott Kitterman wrote: > On September 28, 2023 3:22:20 PM UTC, Bastian Germann wrote: > >Okay. What do you suggest for "team maintained" packages where there is > >no active team member? File MIA processes for each of the uploaders? > >And then? The MIA team's bugs are not RC bugs, so you cannot even NMU > >them based on the MIA bug. > > > >I think, just letting such packages rot for one or two decades does not > > help anybody, certainly not our users. > Any team member can orphan the package. A team with 99 MIA members one active is not the problem here. But we have oh so many packages where the whole team is gone. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ ⠈⠳⣄
Re: Bug#1053165: ITS: nunit
Hi Bastian, I'd just want to chime in and confirm what David wrote aleady. When we wrote the ITS procedure during Debconf Tawain, it was an explicitly designed that way, that it must not be a way to fast-orphan packages, bypassing the processes we have for that. This was intentional engineered that way, e.g to balance the procedure and the maintainers expectations, e.g to increase the acceptance of the "new procecure" in the project. IF you are interested in the Some of the thought and rationales, I encourage you to read the announcment back then [1] [1] https://lists.debian.org/debian-devel/2018/07/msg00453.html On Thu, Sep 28, 2023 at 05:22:20PM +0200, Bastian Germann wrote: > Okay. What do you suggest for "team maintained" packages where there is no > active team member? > File MIA processes for each of the uploaders? Yes, involve the MIA team. > And then? The MIA team's bugs are not RC bugs, > so you cannot even NMU them based on the MIA bug. > I think, just letting such packages rot for one or two decades does not help > anybody, certainly not our users. Orphaning will not magically cure bit-rot or fix the unmaintained package problem. As written somewhere else in this thread, NMU needs to fix bugs, but if something is bit-rotted, there should be reported bugs, the bugs need *not* to be RC and even wishlist bugs can be (and I have done this) in the the scope of an NMU, especially if they are reported since a while. -- tobi (as MIA team member and author of the ITS process) signature.asc Description: PGP signature
Re: Bug#1053165: ITS: nunit
On 28/09/23 17:22, Bastian Germann wrote: Okay. What do you suggest for "team maintained" packages where there is no active team member? File MIA processes for each of the uploaders? And then? The MIA team's bugs are not RC bugs, An automatic time-based "orphaning + RC" process like the one described in [1] would solve (or greatly reduce) of most of these issues. I think, just letting such packages rot for one or two decades does not help anybody, certainly not our users. I'd say that this whole discussion reinforces the need for a third option between "it's fully maintained" and "it's orphaned" [2]. A third option that recognizes and provides rules for low-commitment QA work on non-actively maintained packages. [1] https://lists.debian.org/debian-devel/2023/09/msg00237.html [2] https://lists.debian.org/debian-devel/2023/09/msg00358.html Regards, -- Gioele Barabucci
Re: Bug#1053165: ITS: nunit
On Thu, 28 Sep 2023 17:22:20 +0200, Bastian Germann wrote: >Okay. What do you suggest for "team maintained" packages where there is no >active team member? >File MIA processes for each of the uploaders? And then? The MIA team's bugs >are not RC bugs, >so you cannot even NMU them based on the MIA bug. > >I think, just letting such packages rot for one or two decades does not help >anybody, certainly not our users. > I interpret it as you can NMU even if it doesn't fix RC bugs, see devref 5.11.1: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus Different delays for "only release-critical" in combination with important bugs - and then "Other NMUs: 10 days" - which to my interpretation also means fixing non-RC bugs. Of course you should always give the maintainer a chance to react though. -- Andreas Rönnquist mailingli...@gusnan.se andr...@ronnquist.net
Re: Bug#1053165: ITS: nunit
On Sep 28, Bastian Germann wrote: > Okay. What do you suggest for "team maintained" packages where there is no > active team member? > File MIA processes for each of the uploaders? And then? The MIA team's bugs > are not RC bugs, > so you cannot even NMU them based on the MIA bug. After having verified that none of the current maintainers object (tacit consent is fine) then just NMU them. > I think, just letting such packages rot for one or two decades does not help > anybody, certainly not our users. I agree: you are doing a good thing by caring about abandoned packages. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1053165: ITS: nunit
On September 28, 2023 3:22:20 PM UTC, Bastian Germann wrote: >Okay. What do you suggest for "team maintained" packages where there is no >active team member? >File MIA processes for each of the uploaders? And then? The MIA team's bugs >are not RC bugs, >so you cannot even NMU them based on the MIA bug. > >I think, just letting such packages rot for one or two decades does not help >anybody, certainly not our users. > Any team member can orphan the package. Scott K
Re: Bug#1053165: ITS: nunit
Okay. What do you suggest for "team maintained" packages where there is no active team member? File MIA processes for each of the uploaders? And then? The MIA team's bugs are not RC bugs, so you cannot even NMU them based on the MIA bug. I think, just letting such packages rot for one or two decades does not help anybody, certainly not our users.
Re: Bug#1053165: ITS: nunit
Hi, Quoting David Bremner (2023-09-28 16:40:13) > Bastian Germann writes: > > Source: nunit > > > > I intend to salvage nunit with the plan to orphan it in three weeks. > > Please notify me if you object. > > In my opinion, your repeated "salvaging" of packages in order to orphan > them is an abuse of the ITS process. Yes, it's a clever procedural hack, > but Debian is not (supposed to be) about tricking our fellow > developers. I don't know what best process to do the QA work you want to > do is; I suspect you should consult the MIA team for suggestions. > > David > > - who co-wrote the ITS process, and knows what it says. I don't think it's a clever hack. It would be a hack if it at least works within the given set of rules. But devref specifically says: "Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time." So salvaging a package with the intention to orphan it is clearly violating the explicit rules of the salvaging process. So I do not think whether or not this approach is wrong is a matter of opinion. It is clearly written down that you should only salvage if you "intend to maintain the package for a prolonged time". I like a lot that we have the salvaging process in place. Please do not taint it by breaking its rules. Thanks! cheers, josch signature.asc Description: signature
Re: Bug#1053165: ITS: nunit
Bastian Germann writes: > Source: nunit > > I intend to salvage nunit with the plan to orphan it in three weeks. > Please notify me if you object. In my opinion, your repeated "salvaging" of packages in order to orphan them is an abuse of the ITS process. Yes, it's a clever procedural hack, but Debian is not (supposed to be) about tricking our fellow developers. I don't know what best process to do the QA work you want to do is; I suspect you should consult the MIA team for suggestions. David - who co-wrote the ITS process, and knows what it says.
