Steve Langasek <[EMAIL PROTECTED]> writes: > Re-uploading a package to provoke a buildd response is counterproductive, > *particularly* when the package is already in Needs-Build on the missing > architectures. Re-uploading doesn't change its position in the queue, but > it *does* force buildds for all the other archs to needlessly rebuild the > package. This is why the answer to your previous email was "please be > patient".
Unfortunately, the queue ordering policy is unclear. I was guessing that the priority of the upload would have something to do with queueing policy. Since the all but one of the other arch buildd's have empty needs-build queues, it is harmless to force them to execute a recompile and costs no scarce resources. I did check this before uploading. I made an upload because a related package (grisbi) just seemed to get compiled by all the buildd's in a nifty two-day round trip time. It was uploaded March 10, compiled by most buildds on the 10th, and by arm and mipsel on the 11th. I concluded that the queue must take note of priority or something like that. Perhaps it got through the queue because the grisbi upload fixed an serious RC bug. Well, the gnucash one fixes a critical RC bug, but that isn't indicated in the changelog. Maybe I should add that? If, perhaps, there was a clear indication of the buildd ordering policy, then it could be properly used. Until then, I go on the basis of guesswork. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
