220724 - Provide standalone bug submission program

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Christian Reis]

Eric and I have been hacking on a bug submission program written in Python. This
program provides a simple commandline interface to submit bugs to a Bugzilla
instance. 

We've agreed on the basic interface, and I'm in the process of polishing it up
for submission.

Comment 1

[Gervase Markham [:gerv]]

/me is amused that "standalone" and "written in Python" are in the description
together ;-) Presumably it doesn't stand alone from the Python interpreter?

Gerv

Comment 2

[Dave Miller [:justdave]]

Shiva, here's the bug-submission program I was telling you about.

Comment 3

[Christian Reis]

Well, it's a fact that most modern distributions include a Python interpreter,
and we only require standard modules.

And it does "standalone" from an interpreter; it just won't do anything useful
in that case <wink>

Comment 4

[Gervase Markham [:gerv]]

So, this is a standalone-for-Linux bug submission program? ;-)

Seriously, I'm just teasing you. Although I'd prefer it was written in Perl
(then I could hack on it), this is a great idea. And I'm sure any server-side
interfaces you make will be language-neutral.

Gerv

Comment 5

[Christian Reis]

Who says you can't hack on Python? :-) (And note that Python is now distributed
with MacOS X, too!)

Eric, what would you say of attaching the current status of our work?

Comment 6

[esr]

Attachment: Working version of the bug-submission script

This is ready to be announced with the next Bugzilla point release.  I'll
include
the XML for the manual page in another attachment.

A possible improvement would be to use RDF to do more efficient field
validation. I tried this, but it turns out the RDF fieldnames don't match
the internal ones in the bug form.  This needs to be fixed -- and if the fix
involves changing the internal field names, this script will need to be
modified to match.
internal names,

Comment 7

[esr]

Attachment: Manual page for the submission script, in XML-DocBook

Comment 8

[Christian Reis]

Comment on attachment 132855 [details]
Manual page for the submission script, in XML-DocBook

Eric, apparently you attached the wrong file here. 

Can you tack on the original file?

Also, I was wondering if we could check in generated versions (text/man) so
that users can easily access them without processing the docbook.

Comment 9

[Christian Reis]

Attachment: README file

My plan is to:

mkdir contrib/bug-bugzilla/

and check in the README, the script and the documentation (in all formats) into
this directory.

Comment 10

[Christian Reis]

Requesting approval based on my plan.

Comment 11

[esr]

Attachment: Manual page in XML

Comment 12

[Christian Reis]

Attachment: committed patch

For posterity.

Comment 13

[Christian Reis]

Checked this bugger in. Thanks for the great work, Eric.

/cvsroot/mozilla/webtools/bugzilla/contrib/README,v  <--  README
new revision: 1.6; previous revision: 1.5
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/README,v  <--  README
initial revision: 1.1
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/bug-bugzilla,v  <-- 
bug-bugzilla
initial revision: 1.1
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/bug-bugzilla.xml,v  <--
 bug-bugzilla.xml
initial revision: 1.1
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/bugdata.txt,v  <-- 
bugdata.txt
initial revision: 1.1

Comment 14

[Gervase Markham [:gerv]]

Er... hang on a sec. 

Did no-one yet ask the question "what sort of name is 'bug-bugzilla' for a
standalone submission program?" It sounds like it was thought up by a process
involving a misunderstood conversation with a guy with a stutter. It says
absolutely nothing about what the software actually does.

Gerv

Comment 15

[esr]

Gervaise, it's a program for bugging bugzilla about a bug.

Comment 16

[Gervase Markham [:gerv]]

That's "Gervase" :-)

It's not a program for bugging Bugzilla about a bug. To bug someone about
something, at least over here in England, means to remind them at regular
intervals until they do something about it. That's not what this program does
(nor would a program which did that make any sense; when you tell Bugzilla about
something, it remembers it the first time, unlike humans.)

Gerv

Comment 17

[Christian Reis]

For the record we did consider other names before checking in the code. It's a
shame that I didn't CC: developers on this matter, though the timing probably
means nobody would have answered in time for checkin (to meet today's release).
We considered names such as openbug, newbug, etc.

I don't personally think bug-bugzilla is a bad name; it identifies bugzilla
clearly, and it's not obscure or hard to find in a bash <tab> completion for bug
(much better than new/open-* would have been). Having said that, I'd consider
renaming everything *if* someone can come up with a better name. Suggestions
welcome.

Comment 18

[Gervase Markham [:gerv]]

> nobody would have answered in time for checkin (to meet today's release).

Well, I've commented even without the mail, and the release hasn't happened yet. :-)

Some suggestions, then. (I'm surprised ESR's Software Release HOWTO doesn't have
guidelines on naming projects, actually...)

createbug
Or, if you want it to start with "bug", then:
bugcreate
or
bug-create

You can replace "create" with "new" or "open" if you like, but I like "create" best.

This latter form establishes a prefix so we can later have bugalter/bugmodify.
Or perhaps just call it bzclient or something like that, and have a parameter
--create, allowing extension later for --modify and so on.

Gerv

Comment 19

[Dave Miller [:justdave]]

My personal opinion:  It's in the contrib directory.  It's what the author
decided to call it.  There wasn't anything else in the contrib directory already
using that name.  So I don't really care. :)