arsenal-devel team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Fri, Mar 26, 2010 at 02:26:07PM -0700, Brad Figg wrote:
> On 03/24/2010 02:28 PM, Bryce Harrington wrote:
> >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().
> 
> Since the arguments are essentially typeless, this is difficult to do. The
> only thing I can think of right off they top of my head is to use 'type()'
> to figure out if the argument is a simple string or a list and handle it
> appropriately.

Yeah that's sort of what I was thinking.  Well, a minor detail.

> >  * 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
> >
> 
> Not overly difficult, just a bit of work to do. Also, we need to recognize
> that different teams/source-packages require different logs. However, the
> actuall processing of the logs independent of which ones we require should
> be centralized.

Right.  It's certainly true that different teams require different logs,
however keep in mind that it's extremely common for us to bump bug
reports around between us, so if our scripts recognize the breadth of
different kinds of log files that *could* appear on random bug reports
could actually tend to help out a bit.

> >  * Create an AttachmentParser virtual class, with subclasses that can
> >    parse specific attachments of interest:
> >
> >    + dmesg
> >    + lspci
> >    + dmidecode
> >    + Xorg.0.log
> 
> Agree, have done some work in this area already that should be useful.
> 
> >
> >  * 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.
> 
> Agree. A config file could do it easily especially if the config file were
> a json file which we load.

Ahh, yes excellent idea.  To go one further, we could support having two
config files - one local in ~/.local/arsenal/ and another loaded from a
remote URL.  This would allow teams to have a common config file shared
across all team members.

> >  * Distro tagging ('lucid', 'kubuntu', etc.) should be a general routine
> >    in Arsenal itself.  Several scripts are doing this.
> 
> Agree, this is a standalone script I'm going to start on soon with the
> intention of the core being put into the Arsenal library.
> 
> >
> >  * 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).
> >
> 
> This all sounds good, just going to take a bit of work to implement.

Yup.

Btw, I've had a few GSoC students take interest in working on arsenal
this summer, so I've started a TODO file in the top of the code tree
with some simple tasks for arsenal newbies to get their feet wet with.
(Documentation, tests, janitorial work, etc.)  Please feel free to add
further ideas to that file as you think of them.

Bryce