On Mon, Nov 17, 2008 at 6:42 PM, Robert Collins
<email address hidden> wrote:
> On Mon, 2008-11-17 at 10:42 +0000, Stuart Bishop wrote:
>> This branch adds an option to process a single item in the queue rather than all items in the queue.
>>
>> Launchpad development needs this as scripts regularly changing the config file used by pqm and we need these changes to take effect immediately after the current job.
>
> Would it be worth just making pqm reevaluate the config after every
> script? That would seem to have little performance impact and be simpler
> for users than an option to unbreak things.
This would involve us altering the config in place or using a symlink
to switch between configs. We could do it that way, but it seems
uglier and gives us no easy way to tell which config a currently
running instance is using (hmm... that use case smells like a YAGNI,
but anyway...)
One thing I was thinking of - depending on how our experiment with
continuous integration instead of test-before-commit goes, we might
want to implement a hold/skip filter to PQM.These jobs are just
skipped rather than being rejected or processed. This would allow jobs
to be backed up when PQM is running in a mode where they cannot be
landed rather than rejecting them and requiring people to resubmit. If
we took the approach of reloading the config after each run, rather
than just processing a single job each invocation, then jobs may end
up being processed out of order when the config is changed several
times when the queue is being processed. This again is probably a
YAGNI.
Reloading the config would be useful for other tasks though, such as
most of the use cases for stop.patch.
On Mon, Nov 17, 2008 at 6:42 PM, Robert Collins
<email address hidden> wrote:
> On Mon, 2008-11-17 at 10:42 +0000, Stuart Bishop wrote:
>> This branch adds an option to process a single item in the queue rather than all items in the queue.
>>
>> Launchpad development needs this as scripts regularly changing the config file used by pqm and we need these changes to take effect immediately after the current job.
>
> Would it be worth just making pqm reevaluate the config after every
> script? That would seem to have little performance impact and be simpler
> for users than an option to unbreak things.
This would involve us altering the config in place or using a symlink
to switch between configs. We could do it that way, but it seems
uglier and gives us no easy way to tell which config a currently
running instance is using (hmm... that use case smells like a YAGNI,
but anyway...)
One thing I was thinking of - depending on how our experiment with
continuous integration instead of test-before-commit goes, we might
want to implement a hold/skip filter to PQM.These jobs are just
skipped rather than being rejected or processed. This would allow jobs
to be backed up when PQM is running in a mode where they cannot be
landed rather than rejecting them and requiring people to resubmit. If
we took the approach of reloading the config after each run, rather
than just processing a single job each invocation, then jobs may end
up being processed out of order when the config is changed several
times when the queue is being processed. This again is probably a
YAGNI.
Reloading the config would be useful for other tasks though, such as
most of the use cases for stop.patch.
-- www.stuartbisho p.net/
Stuart Bishop <email address hidden>
http://