Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Adam Borowski]

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?)

[Gert Wollny]

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?)

[Thomas Goirand]

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?)

[Christoph Biedl]

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?)

[Thomas Goirand]

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?)

[Philipp Kern]

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?)

[Marvin Renich]

* 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?)

[Scott Kitterman]

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?)

[Marvin Renich]

* 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?)

[Lars Wirzenius]

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?)

[Mattia Rizzolo]

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?)

[Simon McVittie]

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=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?)

[Ben Finney]

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?)

[Christoph Biedl]

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?)

[Holger Levsen]

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?)

[Adam Borowski]

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!)?