arsenal-devel team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

process-new-bugs.py is a horribly ugly hack of a script.  It's also
probably the most helpful script in arsenal.  It needs TLC.

After chatting with Brad about it last Friday, I looked through his
changes and the code in general, and itemized some refactoring tasks
would strongly improve the script.  See below.

Brad, if you're interested in implementing some of these things, let me
know so we can coordinate efforts.  Or if you 

 * Could append_tag() and append_tags() be merged into one routine?  If
   not, then append_tag() should just be a wrapper around append_tags().

 * Be better at detecting workflow bugs ("Please...", "Needs sync...",
   etc.) and not asking for files in these cases.

 * Redo the attachment detection/classification code.

   + Move into Arsenal itself for general use
   + Recognize a wider variety of attachments
   + Recognize and flag patches
   + Differentiate between debdiffs and regular patches
   + Recognize tarballs and compressed files and flag them as such

 * Create an AttachmentParser virtual class, with subclasses that can
   parse specific attachments of interest:

   + dmesg
   + lspci
   + dmidecode
   + Xorg.0.log

 * Symptom tagging.

   + Extract logic from process-tagging.py, which is more polished.
     Move into Arsenal library proper

   + The tags_regex table is X.org-specific.  We need an easy way for
     other teams to provide their own tables.  Maybe load from a config
     file or something.

 * Distro tagging ('lucid', 'kubuntu', etc.) should be a general routine
   in Arsenal itself.  Several scripts are doing this.

 * Message replies.  I am not happy with how this is implemented in
   process-new-bugs.py.  My ideal would be some magic routine which
   could write a customized reply specific to what it sees, so it's
   specific and doesn't sound so canned.  This is what I was shooting
   for with the ArsenalReply class, but that's unfinished.  This needs
   to be heavily re-thought out.

   + Use the identified symptoms to determine if the appropriate
     attachments are present on the bug.  If not, prompt the user to add
     them.

   + Use the identified symptoms to give advice (or wiki pages) with
     info about working around the problem.

   + Identify if bug was reported against a released version and prompt
     use to test the development version (if appropriate).