Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Fri, Feb 02, 2018 at 08:54:37AM +0100, Christoph Biedl wrote: > Thomas Goirand wrote... > > > We already have RFA, where maintainers are asking for adoption. I fail > > to see how a different type of bug will trigger a quicker adoption. An > > ITR is going to (unfortunately) achieve the exact same thing as an RFA, > > which in most cases is ... no much. > > I disagree. The messages are ... > > RFA: If somebody wishes to take over, please get in touch. > O: If you want to take over, it's yours. > ITR: Somebody take over, otherwise the package will be gone soon. That would be redundant, merely a yet another stage that's not really needed. RFA/O are about whether there's someone willing to do the work, without a message about the package being useful or not. ITR (or an usertag) would be a query if the package is useful, with no statement about whether you're willing to do the work or not. Ie, there's no "somebody take over", as you may be okay with keeping the package -- you no longer need it yourself, but can continue maintaining it, as long as there are actual users who care. > So for me the anger is mostly about the silence and the (sometimes) > haste of an RM. I was glad if RMs had to follow a certain procedure > which boils down to notifying more places and giving a grace period of, > say, two weeks. Which is what in my understanding an ITR would do. If > you just don't want to introduce a new name for this augmented RM, be my > guest. I wouldn't want to spam the FTP team with a thousand of RMs they're not supposed to handle yet. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration ⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)? ⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet ⠈⠳⣄ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
Am Freitag, den 02.02.2018, 09:32 +0100 schrieb Thomas Goirand: [...] > O: Package is unmaintained, hurry or the package is in danger to be > removed. I risk to differ, if this were so, we wouldn't have +700 packages that have the QA team as maintainer, and quite a few have a five or even six-figure popcorn. Orphaning a package does not imply an intent to remove the package and apparently quite a number of packages don't need much maintainance apart from a binary rebuild once in a while. > If you introduce ITR, then RFA will become meaningless. Let's not do > that and improve the RM bug procedure as you suggest below. Anyway, I also think that an extra ITR is not needed, but the RMs should be more visible if they don't just relate to cruft. For instance for packages that are not RC buggy or have other important reasons to be removed and are not yet orphaned it would be nice if the package would be orphaned before removal is requested to give others the opportunity to take over, maybe in this case with a tag "removal pending if not adopted within X weeks". [...] My 2 cents, Gert
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On 02/02/2018 08:54 AM, Christoph Biedl wrote: > Thomas Goirand wrote... > >> We already have RFA, where maintainers are asking for adoption. I fail >> to see how a different type of bug will trigger a quicker adoption. An >> ITR is going to (unfortunately) achieve the exact same thing as an RFA, >> which in most cases is ... no much. > > I disagree. The messages are ... > > RFA: If somebody wishes to take over, please get in touch. > O: If you want to take over, it's yours. > ITR: Somebody take over, otherwise the package will be gone soon. My reading is a way more radical. To me: RFA: Please adopt it, I lost interest and the package is bit-rotting. I'm doing the bare minimal work. O: Package is unmaintained, hurry or the package is in danger to be removed. ITR: No meaning, see "O:" that already covers it... If you introduce ITR, then RFA will become meaningless. Let's not do that and improve the RM bug procedure as you suggest below. > Assuming the ITR gets a broader audience than the RM, like d-d and the > packages's qa address: It's a sign of high urgency Orphaning is already a sign of urgency, since it means there's no maintainer anymore. We don't need anything else. > While RFA/O mostly show > up in the weekly WNPP report, and while I read this, packages of my > interest usually trigger a feeling of: While I could take some of those, > looking at my time budget, I should rather not. And hopefully somebody > else will jump in. Having ITR wont change the fact you have other priorities (ie: to be read as "no time for it", as this is the same thing). > I was glad if RMs had to follow a certain procedure > which boils down to notifying more places and giving a grace period of, > say, two weeks. There's many reasons why a RM can take place, sometimes it's not at all about stopping maintenance. For example, I was maintaining python-pyldap, which was a fork of python-ldap, but it got merged back, so pyldap had no meaning anymore as soon as ldap was in version >= 3. In such case, RM as quick as possible is the way to go. However, in the case we're discussing (ie: lost of interest by the current maintainer), I agree we could add a mandatory delay, probably by adding some kind of field in reportbug. > If you just don't want to introduce a new name for this augmented RM, be my > guest. Definitively, IMO it should be kept within the boundaries of the RM bug. That's the thing we could improve to avoid RM-ing packages too fast, and advertise when a package is being removed. Cheers, Thomas Goirand (zigo)
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
Thomas Goirand wrote... > We already have RFA, where maintainers are asking for adoption. I fail > to see how a different type of bug will trigger a quicker adoption. An > ITR is going to (unfortunately) achieve the exact same thing as an RFA, > which in most cases is ... no much. I disagree. The messages are ... RFA: If somebody wishes to take over, please get in touch. O: If you want to take over, it's yours. ITR: Somebody take over, otherwise the package will be gone soon. > See this one (of mine) as an example: > https://bugs.debian.org/880416 > > it's just bit-rotting. I've told a few people vaguely interested in the > package that I will RoM it soon. No action so far. I'm quite sure the > only path is to actually remove the package. Someone may then pick it up > because of the removal, but IMO that process can only be speed up by > actually removing the package faster, not slower. Adding an ITR wont help. Changing this to ITR would tell "This is your last chance". Assuming the ITR gets a broader audience than the RM, like d-d and the packages's qa address: It's a sign of high urgency, and anybody who is even remotely interested should stand up *now*. While RFA/O mostly show up in the weekly WNPP report, and while I read this, packages of my interest usually trigger a feeling of: While I could take some of those, looking at my time budget, I should rather not. And hopefully somebody else will jump in. Actually removing the package in the silent way it happens right now carries a high risk the next release will ship without it, as users of stable will not notice until the next dist-upgrade. So for me the anger is mostly about the silence and the (sometimes) haste of an RM. I was glad if RMs had to follow a certain procedure which boils down to notifying more places and giving a grace period of, say, two weeks. Which is what in my understanding an ITR would do. If you just don't want to introduce a new name for this augmented RM, be my guest. Christoph signature.asc Description: PGP signature
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On 02/01/2018 01:12 AM, Adam Borowski wrote: > One issue: on a small screen, crap font and no glasses, "ITR" looks similar > to "ITP", an alternate acronym could be better. > > Meow. Hi, I very much appreciate your intent here, which is for sure, to make Debian nicer and more welcoming. However, my guts are telling me this is counter-productive. Let me share. We already have RFA, where maintainers are asking for adoption. I fail to see how a different type of bug will trigger a quicker adoption. An ITR is going to (unfortunately) achieve the exact same thing as an RFA, which in most cases is ... no much. See this one (of mine) as an example: https://bugs.debian.org/880416 it's just bit-rotting. I've told a few people vaguely interested in the package that I will RoM it soon. No action so far. I'm quite sure the only path is to actually remove the package. Someone may then pick it up because of the removal, but IMO that process can only be speed up by actually removing the package faster, not slower. Adding an ITR wont help. Actually, let me RoM the package right away now... done! See #889099. Let's see if someone complains now. If this happens (which I expect), it will prove my point: the issue we're having isn't the lack of ITR, but the fact that nobody acts on RFAs. If it doesn't happen, then it means I could (and should) have file the RoM bug earlier. In both cases, removing the package earlier from the archive was the best thing to do. Cheers, Thomas Goirand (zigo)
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On 2018-02-01 15:03, Scott Kitterman wrote: I agree that the FTP team should not second guess the maintainer's removal request. However, with or without a new ITR process, I think it would be justified (and good practice) for the FTP team to start requiring the maintainer to record in the bug the reasoning behind the removal. This appears to be common, but not universal, practice when filing ROMs, but making it mandatory and enforced by the FTP team does not seem out of line. This has nothing to do with second guessing; it is about openness to the rest of the Debian community (esp users who are wondering why their favorite niche package didn't make it into the next release). And as stated elsewhere in this thread, it will help a prospective new maintainer know whether reintroducing the package will be worth the effort. While I agree that would be best, I don't think it's the primary purpose of an rm bug. It doesn't take an FTP team member to ping the maintainer to ask why, cc the bug. If this concerns people, they can ask for more information. Except that there is no requirement anymore to actually answer the question. The bug has been acted upon and closed. Kind regards Philipp Kern
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
* Scott Kitterman [180201 09:04]: > On February 1, 2018 1:47:17 PM UTC, Marvin Renich wrote: > >I agree that the FTP team should not second guess the maintainer's > >removal request. However, with or without a new ITR process, I think > >it would be justified (and good practice) for the FTP team to start > >requiring the maintainer to record in the bug the reasoning behind > >the removal. > > While I agree that would be best, I don't think it's the primary > purpose of an rm bug. It doesn't take an FTP team member to ping the > maintainer to ask why, cc the bug. I think the RM bug should include both what is being requested (removal) and why. I think the two are closely related enough that they should share the title of "primary purpose". However, I know that you and the rest of the FTP team do a tremendous amount of work (thank you very much!), so I will concede that this is one item that should be the responsibility of the bug filer and doesn't need to be on your plate. > If this concerns people, they can ask for more information. True, but that happens after the fact, and sometimes time has a way of helping information to get lost. ...Marvin
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On February 1, 2018 1:47:17 PM UTC, Marvin Renich wrote: >* Mattia Rizzolo [180201 03:26]: >> I seriously doubt ITRs or somesuch would help, you wouldn't notice >them >> anyway. >> If you can parse a list of ITRs you can equally easy parse a list of >> packages with open RC bugs with next to the same effect. > >I disagree. As a user, if I see RC bugs on a package, I have no idea >what work is or isn't being done by the maintainer or others to address >those bugs. However, if the maintainer (or someone close to the >package) files an ITR, I now know that this is my last chance to speak >up. With something similar to apt-listchanges that notifies me when I >do aptitude update that a package I have installed will be removed >soon, >I have an opportunity to react. Something similar for RC bugs would >not >serve the same purpose (though it might be very useful for someone >looking for ways to contribute to Debian: "There are RC bugs on these >packages that you use; would you like to help out?"). > >> RoQA packages without RC bugs is very rare (and I don't like them >> myself), and ROM shouldn't be second guessed anyway (as an ftpteam >> member stated). > >I agree that the FTP team should not second guess the maintainer's >removal request. However, with or without a new ITR process, I think >it >would be justified (and good practice) for the FTP team to start >requiring the maintainer to record in the bug the reasoning behind the >removal. This appears to be common, but not universal, practice when >filing ROMs, but making it mandatory and enforced by the FTP team does >not seem out of line. This has nothing to do with second guessing; it >is about openness to the rest of the Debian community (esp users who >are >wondering why their favorite niche package didn't make it into the next >release). And as stated elsewhere in this thread, it will help a >prospective new maintainer know whether reintroducing the package will >be worth the effort. While I agree that would be best, I don't think it's the primary purpose of an rm bug. It doesn't take an FTP team member to ping the maintainer to ask why, cc the bug. If this concerns people, they can ask for more information. Scott K
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
* Mattia Rizzolo [180201 03:26]: > I seriously doubt ITRs or somesuch would help, you wouldn't notice them > anyway. > If you can parse a list of ITRs you can equally easy parse a list of > packages with open RC bugs with next to the same effect. I disagree. As a user, if I see RC bugs on a package, I have no idea what work is or isn't being done by the maintainer or others to address those bugs. However, if the maintainer (or someone close to the package) files an ITR, I now know that this is my last chance to speak up. With something similar to apt-listchanges that notifies me when I do aptitude update that a package I have installed will be removed soon, I have an opportunity to react. Something similar for RC bugs would not serve the same purpose (though it might be very useful for someone looking for ways to contribute to Debian: "There are RC bugs on these packages that you use; would you like to help out?"). > RoQA packages without RC bugs is very rare (and I don't like them > myself), and ROM shouldn't be second guessed anyway (as an ftpteam > member stated). I agree that the FTP team should not second guess the maintainer's removal request. However, with or without a new ITR process, I think it would be justified (and good practice) for the FTP team to start requiring the maintainer to record in the bug the reasoning behind the removal. This appears to be common, but not universal, practice when filing ROMs, but making it mandatory and enforced by the FTP team does not seem out of line. This has nothing to do with second guessing; it is about openness to the rest of the Debian community (esp users who are wondering why their favorite niche package didn't make it into the next release). And as stated elsewhere in this thread, it will help a prospective new maintainer know whether reintroducing the package will be worth the effort. ...Marvin
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Thu, 2018-02-01 at 08:37 +0100, Christoph Biedl wrote: > Adam Borowski wrote... > > > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove". > > Sounds like a very good idea. For me, I could automatically parse these > and check against the list of packages installed on my systems, or are > used to build packages (thanks for .buildinfo files) outside the archive. > > > After filing the ITR, if no one objects in a period time, the bug would be > > retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP" > > written on them. Such a period could be: > > * (if we decide to CC ITRs to d-devel): short: a week? > > * otherwise: long: 6 months? > > The short period, but not *that* short. I'd expect any reaction will be > pretty soon but allow people to be offline for a week. In the situation > where removal is obviously the right thing to do, waiting months is > mostly horror. When the cost of making a mistake is high, it pays to spend a lot of effort to avoid making them. If the cost of removing a package from testing or unstable is high, we should put in a lot of effort to not removing packages unless we're really sure it's worth it. Taking longer to remove packages, to learn of negative effects such removal would have, is such an effort. On the other hand, there's also a cost to spending a lot of effort to avoid mistakes. Being very careful at all times, and doing things more slowly, tends to slow down development, sometimes by quite a lot. Case in point: Debian used to be fairly careful about removing packages from testing, but in the past couple of release cycles, removal from testing has had a low threshold, and it's been my impression that this has helped us do better releases with less pain. The reason that has worked is that the cost of making a mistake when removing from testing is low. If a package is removed due to having RC bugs, fixing those bugs will let the package back into testing fairly quickly, and automatically. Removing a package from unstable has a somewhat higher cost, but it seems to me that it it's still fairly low. Thus I would advocate keeping the time-until-removal fairly short. In other words, a week should be OK. signature.asc Description: This is a digitally signed message part
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Thu, Feb 01, 2018 at 08:16:31AM +, Simon McVittie wrote: > So for example "RM: RoQA; unmaintained upstream, orphaned, low popcon" > (but with no actually known RC bugs) would go via an ITR bug, but > removals for long-standing RC bugs would usually be immediate? That > sounds fair, and is similar to common practice with "should this package > be removed?" bugs. Except that apparently the OP is complaining about removing a package with RC bugs open for 3+ years with nobody caring enough to notice them and *triaging* (as apparently one was even already fixed…) them. I seriously doubt ITRs or somesuch would help, you wouldn't notice them anyway. If you can parse a list of ITRs you can equally easy parse a list of packages with open RC bugs with next to the same effect. RoQA packages without RC bugs is very rare (and I don't like them myself), and ROM shouldn't be second guessed anyway (as an ftpteam member stated). (btw, many removals requested by Moritz Muehlenhoff are marked RoQA but really are RoST (but did that acronym disapper from the list?!), and that covers a bunch of of the "orphaned pkg removed despite no rc bug") -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Thu, 01 Feb 2018 at 01:12:21 +0100, Adam Borowski wrote: > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove". This sounds like a formalization of the "foo: should this package be removed?" bugs that some people already use[1]. I was wondering whether to suggest formalizing those in devref or something. They should probably be bugs against the package itself rather than wnpp (like the "should be removed?" bugs are), or X-Debbugs-Cc'd to the package's contact address and marked as "affects", or something, to give the maintainer (and other subscribers) one last chance to respond. [1] I thought the canonical usertag for these was https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=proposed-removal&user=debian-qa%40lists.debian.org but that list looks much shorter than I expected it to be, so perhaps I'm wrong (or perhaps the vast majority of proposed removals have escalated to actual removals and so the bug got closed) > As someone who watches the output of qa-rc a lot, most of the time I stare > at the list, ponder "do I fix this? or would RoQA be better?", shrug and > move on. Instead, we could file hundreds of ITRs, wait, then bury the ftp > folks under a pile of removal requests. Regular attendees of #debian-uk bug squashing parties will recognise this pattern already :-) > However, ITRs wouldn't be mandatory: the majority of packages can be removed > outright; you'd file an ITR only if you believe there's some controversy. So for example "RM: RoQA; unmaintained upstream, orphaned, low popcon" (but with no actually known RC bugs) would go via an ITR bug, but removals for long-standing RC bugs would usually be immediate? That sounds fair, and is similar to common practice with "should this package be removed?" bugs. smcv
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
Adam Borowski writes: > One issue: on a small screen, crap font and no glasses, "ITR" looks similar > to "ITP", an alternate acronym could be better. RFI (Request for Interest) RFU (Request for Users) POLL (Participate Or Let's Lose this) -- \“Politics is not the art of the possible. It consists in | `\ choosing between the disastrous and the unpalatable.” —John | _o__)Kenneth Galbraith, 1962-03-02 | Ben Finney
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
Adam Borowski wrote... > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove". Sounds like a very good idea. For me, I could automatically parse these and check against the list of packages installed on my systems, or are used to build packages (thanks for .buildinfo files) outside the archive. > After filing the ITR, if no one objects in a period time, the bug would be > retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP" > written on them. Such a period could be: > * (if we decide to CC ITRs to d-devel): short: a week? > * otherwise: long: 6 months? The short period, but not *that* short. I'd expect any reaction will be pretty soon but allow people to be offline for a week. In the situation where removal is obviously the right thing to do, waiting months is mostly horror. > We could have an offshot of wnpp-alert notify you if a package you have > installed has been ITRed. Perhaps even this could be installed by default, > so users in stable of obscure packages have a chance to act. Certainly, packages to be removed from (old)stable in a point release should go through that procedure aswell. > However, ITRs wouldn't be mandatory: the majority of packages can be removed > outright; you'd file an ITR only if you believe there's some controversy. For this I'd prefer to have a guideline so this isn't entirely left to the submitter's discretion. It boils down to "do no harm". So removing cruft like NVIU certainly can do done straight ahead, while ROM/ROP/RoQA should get some audience and time. > One issue: on a small screen, crap font and no glasses, "ITR" looks similar > to "ITP", an alternate acronym could be better. Removal Intent for a Package? (jk) Christoph signature.asc Description: PGP signature
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Thu, Feb 01, 2018 at 01:12:21AM +0100, Adam Borowski wrote: > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove". > It's pretty much the opposite of O: [...] > * by filing an ITR, you don't disclaim your commitment to the package (if > you're the maintainer, you may or may not be willing to continue working > on it) -- but instead, you declare doubt whether the package is still > needed. [...] I like this! -- cheers, Holger signature.asc Description: PGP signature
proposal: ITR (was Re: Removing packages perhaps too aggressively?)
On Wed, Jan 31, 2018 at 08:14:31PM +0100, Andrej Shadura wrote: > It has happened to me in the recent years quite a few times that a > package which I was using has a RoQA bug filed against it, and the > package's got removed at a very short notice. For example, dasher was removed (by its maintainer!) because he believed no one cares about it; the packages wasn't even orphaned. No one monitors FTP bugs, the ftpmasters acted swiftly, and the flamewar started only after the removal was completed. On the other hand, we have thousands of crap packages no one cares about, in all three states of maintenance: * orphaned * nominally "maintained" * with a maintainer who actually fixes bugs yet no one removes them because we don't _know_ whether users would get hurt, or merely move to an alternative. Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove". It's pretty much the opposite of O: * if you orphan a package, you claim that you (or the old maintainer) don't have enough time, but you believe that Debian is better off with the package being kept in the archive (batched orphaning (such as by the MIA team) makes no statement for the latter part, but that still means no assessment rather than a negative one) * by filing an ITR, you don't disclaim your commitment to the package (if you're the maintainer, you may or may not be willing to continue working on it) -- but instead, you declare doubt whether the package is still needed. After filing the ITR, if no one objects in a period time, the bug would be retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP" written on them. Such a period could be: * (if we decide to CC ITRs to d-devel): short: a week? * otherwise: long: 6 months? We could even have a mix of both of these: packages likely to evoke a controversy could be discussed upon on d-devel then handled as soon as the flamerwar abates, while QA spring cleaning would be quiet, massed, and without haste. We could have an offshot of wnpp-alert notify you if a package you have installed has been ITRed. Perhaps even this could be installed by default, so users in stable of obscure packages have a chance to act. As someone who watches the output of qa-rc a lot, most of the time I stare at the list, ponder "do I fix this? or would RoQA be better?", shrug and move on. Instead, we could file hundreds of ITRs, wait, then bury the ftp folks under a pile of removal requests. However, ITRs wouldn't be mandatory: the majority of packages can be removed outright; you'd file an ITR only if you believe there's some controversy. So, let'd discuss! One issue: on a small screen, crap font and no glasses, "ITR" looks similar to "ITP", an alternate acronym could be better. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration ⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)? ⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet ⠈⠳⣄ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?