================= QA Assistant TODO ================= :Author: Toshio Kuratomi :Contact: toshio-tiki-lounge.com :Date: $Date: 2006-04-24 16:46:23 -0700 (Mon, 24 Apr 2006) $ :Revision: $Rev: 214 $ .. contents:: glade/GUI: ========== * Create a logo to go along with the icon. Think up some other small pixmaps for the menu/toolbar: toggle Preview, new from bugzilla, new from SRPM, Publish Report, Submit Report * When the reviewer really should add additional information in a note, how should we make it happen? A field in the XML file under state? And that causes qa-assistant to pop up a textEntry dialog when the item enters that state? Perhaps the checklist needs to define something in the state field: Install time scriptlet needs to List problems here * Add i18n support. Functions: ========== * These require integration with the Functions features - Publish Button should be added to toolbar [Need icon] + Pressing Submit will build the review and submit to bugzilla. [Needs to have a function written and registered in fedoraus.py] - Add a New dialog to take input about bugzilla [Now a property to take a bugzilla URL] + If new then make sure we have both a bugzilla # and an SRPM [Needs to be implemented via properties] * Security: We need to fill in two pieces here: 1) The checklist needs to be gpg signed. 2) We have to check that byte-compiled function files are valid If we can set the interpreter to always byte compile the functions then that should work. Extra GNOME Functionality: ========================== * Update to pygtk-2.4. - Embed the 2.4 file selector widget in the druid. [Loading may be separated from the druid]. - Switch to the 2.6 ComboBox Renderer instead of optionrenderer. - Convert from self.__gobject_init__()/gobject.GObject.__init__() to gtk.CLASSNAME.__init__(self) since the changes to make this work are in 2.6 (May have gone into 2.4) + optionrenderer + treetips + checklist Programming: ============ * Revamp Druid. On start, QA-Assistant will display a blank page. If the user selects New they will be taken into the Druid. If they select load they will just get a file selection dialog. The Druid will only deal with new Reviews, which simplifies it a bit. - Remove the load savefiles pathway out of the Druid. - On startup, display a blank QA Assistant Main Window, not the Druid. - When the druid is active, make it modal so the MainWindow is not focusable. - Properties checking (for entry of required values) is done by the Properties themselves. Druid on new, PropDialog, and Review:Publish will utilize these checks. Load will not as Outputting the Review will take care of this. [Check how close to done this is. Only part of it is in the Druid.] - File chooser needs to use the directory we last used to save/load from. [Check how close to done this is. It is in the load a savefile section, not in the Druid.] * Command line argument parsing - If a savefile is given, open that - Use optparse/optik * Enhance tracking entries into the editor. We want people to be able to shift text around from Needswork and Non-blocker, and to add to them but we want to keep track of what entry is associated with what entry id. * Automate some review tasks in fedoraus/fedoraextras checklist. - checkheader - checksig - verify source against spec file/canonical URL - look at the new fedora-startqa for more ideas. Perhaps we can coordinate and use fedora-startqa in the backend. (Look through their SRPM stuff -- it might be better code than I have. If it's in a SRPM class like I have, then it could be callable from either my script or theirs.) * Update to the fedora QAFormat output style (QAFormat is somewhat dead) * XML stuff to conform better with libxml2's guidelines document: file:///usr/share/doc/libxml2-devel-2.6.6/guidelines.html (Namespace, URL, Make sure I follow recommendations for element/attribute) * Create a common XML save format/checklist with Erik LaBianca for the checklist. This will involve integrating XML with test infrastructure. (This is stalled. Erik La Bianca has moved on. Aurelian Bompard is maintaining fedora-startqa. Need to look closely at that to figure out what can be shared.) * Implement or document how to write a property that is set automatically by a function but can be overridden by the user. It is simply done by defining a function that sets the value of a non-automatic property. Whether the user or the function has the initial say is decided by the function-writer. It is the function's responsibility to check whether it is overriding a user's entered information. * Functions may interact with the program in a few more ways: - Set the application's title bar: app.set_title(). This can be used to change how to identify the review (checklist name; srpm under review, etc.) - Application's status bar: app.mainWinAppBar.push(). This is useful for setting the number of pass/fail/needs-reviewing entries. (This may fall into the realm of the checklist proper rather than functions...) DTD === * Write a proper check that we can use a file (os.access doesn't work for this purpose. [How does review.py do this?] [Why does os.access not work?]) - For both review.py and savefile we could use try: except IOERROR: to trap failure to write the file. * Separate error dialogs from the widgets. Error dialogs should be created by QAReviewer. Subordinate widgets (like review) should raise an Exception when the encounter an error and qareviewer should then display the error dialog, allow the user to fix it, and rerun the subordinate widget's function. - May not apply to the Druid. Build: ====== * Fix the uninstalled_file lookups - DTDs have to be selected correctly when the program isn't installed. This can be done by setting a libxml environment variable XML_CATALOG_FILES. May also be possible to use xmlCatalogAddLocal() to do this. Also look into: xmlCatalogResolve(),xmlCatalogLocalResolve() Family of functions. Setting XML_DEBUG_CATALOG will allow us to debug what's going on. http://www.xmlsoft.org/catalog.html - Program should use uninstalled files only when it is uninstalled. If it is installed but happens to be run in a build directory, it needs to recognize that. Also, there is currently a small period where the program searches for uninstalled files when it is installed. This needs to be changed so installation removes this penalty. - DTDs and the Druid would both have to be special-cased now to make things work uninstalled. The DTDs could work if the user is connected to a network or if I can get libxml2 to recognize a private xmlcatalog. The Druid and the rest of the current consumers of uninstalled_files might be better served by creating an uninstalled version of paths.py that lists the directories inside the source instead of directories in the system. Currently paths.py is built from paths.pyin at build time. We'd need to create one paths.py at build time and a separate one at install time to make this work. + This looks like the way to go. The new objective is to set all information in the paths.py and have minimal setup processing and no special processing in the main body of the program. * Finish writing unittests for the program. We've barely scratched the surface of this. When completed it should allow one to quickly figure out what's working and what's broken in the package. - Basically need a set of unittests for each object defined in the program. Don't yet know how to unittest the widgets. The model objects and the program object should work much better, though. - Look into coverage tools to tell how thoroughly the unittests cover the code. QA Convert ========== * Add commandline parsing to override the checklist type we're to convert to. this becomes more important when we go from 0.4 to 0.5 to 0.6 to 1.0 formats. Documentation ============= I need to write documentation and take screenshots of using QA Assistant. The programmatic interface for opening the documentation is pretty simple. I've got it in and commented right now. In order to create it, though, I need to write the docbook xml. I've come to the conclusion that writing docbook currently lacks quite a bit. I want to be able to write my content and then have something to output it.