Necessity of queue-pr (revisited)

[Steffen Opel]

Salut,

this topic has been discussed in a thread in april 1999, please consult 
the archives for the details.

Basically the question asked was why it is necessary to queue incoming
PRs before filing them, which requires the well known cron job.

The overall conclusion of the thread seemed to be that it wouldn't be a
good idea to let a sendmail filter perform the costly and eventually
error-raising and -returning job of filing PRs.  Hence the split between
'queue-pr --queue' and 'queue-pr --run' with help of the cron job has
been considered a reasonable solution with better control, info and
security, especially when things go wrong.

Now, while setting up a new 4.0 based repository, I had to deal with a
few 'at' related bugs in the 'notify-about-expired-PRs' functionality
(see filed PRs at gnats-gnats).  This resulted in the idea to replace
the cron job with an 'at' based solution, e.g. like so:

- the sendmail alias would be '|queue-pr --queue --run-at'
- queue-pr --queue queues PRs as before, no bit changed here,
and --run-at places an 'at' job 'queue-pr --run' thereafter.

This way the reasonable queue/file split would be retained, the cron job
eliminated and the user would get feedback more instantly (depends on
your curent cron job setting, of course).

I don't know wether 'at' is available everywhere, but GNATS uses it
already and the cron job solution will still be possible anyway.

A working patch for this is on my machine but I'd prefer to hear a few
comments before I may file it as change-request to gnats-gnats.

Thanks and Ciao,
Steffen