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)
Reply to: