PQM

pqm loops without giving feedback

Bug #567333 reported by Vincent Ladeuil
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
PQM
New
Undecided
Unassigned

Bug Description

https://code.edge.launchpad.net/~vila/bzr/for-babune/+merge/23669

I fed the above with feed-pqm from lp:~lifeless/hydrazine/cron revno 75.

This submissioin (let's call it 1) failed but the only feedback was a very concise report in the mp.

I then re-submitted, still with feed-pqm, by mail.

The submission (2) was taken into account, bypassing some other queued ones at that time.

I didn't stay there hitting refresh in my browser but it was processed and tests were passing (thanks to the progress report)

Later on I realized that the submission was processed again (3), the progress report gave me a lower % than before.

I asked Chex to cancel the submission at that point.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 567333] [NEW] pqm loops without giving feedback

Chex didn't actually cancel it AFAICT, cancelling is done on the
https://code.edge.launchpad.net/~vila/bzr/for-babune/+merge/23669<https://code.edge.launchpad.net/%7Evila/bzr/for-babune/+merge/23669>page
by changing 'Queued' to 'Approved'. He probably interrupted it for you
though.

I had a candidate fix for the looping, rt'd to be deployed but it wasn't
deployed last night. Its been deployed as of this morning and we're
evaluating it now.

Revision history for this message
Vincent Ladeuil (vila) wrote :

This happened again with https://code.edge.launchpad.net/~jameinel/bzr/2.0.6-peak-commit-mem/+merge/23718

This may be out of pqm scope, but a merge proposal that pqm start to process should not stay in the 'queued' state so this kind of loop could be avoided.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 567333] Re: pqm loops without giving feedback

agreed, the point is that pqm is crashing when changing it out of queued, so
you need to do it by hand. With LP maintained queues, its much harder to
ensure this can't happen - with the local disk queues, a simple try:
finally: rm foo.patch is enough to ensure that queued items get popped after
attempting to run them.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.