| 1 |
On 03/01/10 22:17, Ioannis Aslanidis wrote: |
| 2 |
> getting control of bugday.gentoo.org and be able to upload our own |
| 3 |
> content would be great. |
| 4 |
|
| 5 |
The current page is said to generate one XML request per bug listed on |
| 6 |
the page for each request. From my experience trying to remove bugs |
| 7 |
from that page yesterday(?) (through clicking on "remove" buttons) I |
| 8 |
have the impression that it's true: Du to page reload times the site in |
| 9 |
it's current form is unusable in the very sense of the word. |
| 10 |
|
| 11 |
Ideas I have on a rather simple rewrite: |
| 12 |
|
| 13 |
- Split the bugday website into two pages: |
| 14 |
- Page "Open bugs" showing |
| 15 |
- open bugday-keyworded bugs (with date of the latest bugday) |
| 16 |
in randomized order |
| 17 |
- Page "Closed bugs" showing |
| 18 |
- closed bugday-keyworded bugs (with date of the latest bugday) |
| 19 |
in some sorted order |
| 20 |
- a ranking with closed bugs per participant |
| 21 |
(as that may not be the assignee such information could |
| 22 |
maybe be encoding into the status whiteboard, somewhere |
| 23 |
we can query it from easily if whiteboard fits for that) |
| 24 |
|
| 25 |
- Do one search request to bugzilla internally, only. |
| 26 |
Should be possible as we're now asking bugzilla for the list |
| 27 |
of bugs instead of asking for details on a list we pass in. |
| 28 |
|
| 29 |
- Simple caching of bugzilla requests for 10 seconds or so. |
| 30 |
Should not hurt the bugday experience much and reduce load |
| 31 |
further. |
| 32 |
|
| 33 |
I could imagine that an ugly prototype with rough-edges of that could |
| 34 |
take two days in plain Python. At the moment I cannot say when and if I |
| 35 |
have these two days, but maybe someone else with time is fire and flame |
| 36 |
for it by now? |
| 37 |
|
| 38 |
|
| 39 |
|
| 40 |
Sebastian |
Archives