This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: get-cygwin-package - for anyone with upload privileges

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

    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 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:

    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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]