mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-07 12:15:51 +00:00
44 lines
2.0 KiB
Plaintext
44 lines
2.0 KiB
Plaintext
The VC_Bonsai implementation does not work. It is included only
|
|
because they will become important. I do not understand the
|
|
interfaces well enought to finish the work and I have no means to test
|
|
them.
|
|
|
|
I have not coded the Image (fortune) system but I have left coding
|
|
hints as to how it would work.
|
|
|
|
I did not code a warnings system with all the warning pages (see
|
|
tinderbox1).
|
|
|
|
I did not code shownote.cgi to allow people who deploy the notice
|
|
board but do not have popup windows to see the notices.
|
|
|
|
I have not updated the client build scripts to work with the new system.
|
|
|
|
I need a Javascript expect to look over the current versions of CVS
|
|
Blame and Tinderbox1 and ensure that I have the best features of these
|
|
javascript programs in tinderbox2/src/lib/HTMLPopUp/MozillaLayers.pm.
|
|
Please keep the code neat and nicely indented.
|
|
|
|
I need to allow the VC system to have a daemon gather the VC
|
|
information and pass it to tinderbox via the same update methods wich
|
|
Builds uses. Then both the tinder.cgi and this new cvs process could
|
|
be run out of cron periodically and the webpages would not be delayed
|
|
if CVS takes a long time to respond this might improve the response
|
|
time of the web updates. Also the OS process scheduler could do a
|
|
better job of scheduling if there were two different processes one
|
|
which was IO bound and one which was CPU bound.
|
|
|
|
It would be really nice if could mail tinderbox the updates which
|
|
apply to the branches of interest, then tinderbox would not have to
|
|
pool and it would get the branch information which it needs.
|
|
|
|
I would like to show the set of bugs which have been closed during
|
|
each time period. The CVS checkins are often being done to close bugs
|
|
it would be helpful to see what the bug numbers are and to have a
|
|
popup which shows the bug summary, who closed it, and other details.
|
|
It would also be handy to see which bugs have been reopened as these
|
|
indicate a problem with the development process. There is no need to
|
|
display bugs which have been opened for the first time. New bugs are
|
|
not related to development activities.
|
|
|