get-cygwin-package - for anyone with upload privileges

[Warren Young]

On 10/17/2012 4:46 PM, Christopher Faylor wrote:
> I've hacked at the get-cygwin-package script

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.

For example, you can repurpose your setup.ini parser:

     [cygrfu]
     root: http://etr-usa.com/cygwin/
     packages: ctags
     version: 5.8-2

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.