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)