[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: PGP signature


Reply to: