I take it this script is run by hand when a human has decided to do
something about an RFU message?

If so, is there a plan or even a wish for getting to a point where a
script can run on sourceware.org (?) and just monitor the list for RFU
messages and handle them all automatically?

If the email contains a string like:

"Please remove 5.42-1" then that package will be removed and temporarily
archived to a tar file in /tmp.

Every natural language processor I've used -- including very well funded
ones like Siri -- require that the human conform to the limitations of
the computer's natural language parser. They give the illusion of
flexibility while they generate frustration by refusing to accept text
that looks similar to forms it does support.

I think it's great that you've gone and done this, Chris. You can
expect people to keep posting RFUs by the copy-paste-edit-send method,
and the current forms are well understood.

My point is that if you ever find yourself wanting to extend the natural
language parser to cover another new case, instead of spending that time
writing more natural language parsing code or a nastygram to the person
who wrote the RFU, stop and consider. It might be better to spend that
time inventing a more robust RFU message format that a script can parse
with 100% confidence: if it parses, it's legal.

That, coupled with info parsed from the package's existing setup.hint
files or the setup.ini file would tell the script everything it needs to
know to do the right thing. This formal RFU is saying that the script
should expect a sourceware.org like release tree at the root path given,
and that the package names found there differ only in the version number.

The "packages:" line allows for single logical packages that are
actually composed of several separate packages:

packages: sqlite3, libsqlite3_0, libsqlite3-devel

This is where parsing setup.ini comes in: it looks for [libsqlite3_0] to
learn that it should expect to find it in "sqlite3/libsqlite3_0" under
the given root, not in "sqlite3".

The formal RFU request doesn't mention -src and -debuginfo because the
tool already has the information to handle them implicitly.

Then you can add tags for exceptional conditions:

[cygrfu]
....
prev: 5.7-1

That would mean "remove 5.8-1 and leave the earlier 5.7-1 as prev".
That as opposed to its default action, which would be to remove 5.7-1
and leave 5.8-1 as prev.

The point of all this would be to get to a point where the script can
monitor the mailing list and be expected to DTRT 100% of the time.

The incentive to you, Chris, is that it potentially gets the human out
of the RFU loop entirely. This should defeat the SHTDI argument, too.
The Someone is one of those with upload privileges who wants a computer
to put them out of a job. :)

The incentive to the package maintainers is that if they use this
format, they know the script will pick up their packages in computer
time, instead of waiting for a human to process an informal RFU. A
package maintainer might therefore have some hope of getting a fix out
to the mirrors within 24 hours of sending the RFU.

You might consider whether to add an email whitelist to this, which
controls whether the script will pay attention to formal RFUs. Newbie
maintainers or those the uploaders don't entirely trust for whatever
reason won't be on the list.

I think that's probably a sign they shouldn't have maintainership at
all, though. The more independence you give the package maintainers,
the fewer synchronization points you have, which is good for speed, as
any experienced computer programmer knows.

That said, a whitelist containing all package maintainers' known emails
is probably still a good thing. You wouldn't want the script accepting
formal RFU requests from random people.