https://bugzilla.wikimedia.org/show_bug.cgi?id=43287
--- Comment #6 from Richard Guk <[email protected]> --- (In reply to comment #5) > Hopefully, all the work Aaron has put into overhauling the job queue code > should mean it's much better from now on. Even more reason to have a way to measure the result of Aaron's work! Not knowing the detail, I can't think why FIFO would not be the preferred picking algorithm, given that the timestamp is indexed; but whatever the method, you'd surely not want any jobs to remain unprocessed for days, weeks or months at a time? > But it is somewhat arbitrary. The job queue count was removed from user view > (Special:Statistics? I think) because it was misleading. It was left in the > API for developers etc. I agree that the size of the queue was not directly relevant to editors. But turning your comment on its head, I would say that editors deserve to know about likely propagation delays (per comment #4), and that the obscurity of the API (from most editors' perspective) means that it would have been far better if [[Special:Statistics]] had added this additional information instead of removing the little information that it used to expose about the queue. Readers expect modern websites to be more-or-less up-to-date. Logged-in editors are used to seeing wiki pages that are current in all other respects. So editors, admins, tech ops and servers all benefit from avoiding enquiries and manual purging by making durations easily identifiable, distinguishing routine high I/O from exceptional delays. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
