Closed Bug 220724 Opened 18 years ago Closed 18 years ago

Provide standalone bug submission program


(Bugzilla :: Creating/Changing Bugs, defect)

Not set



Bugzilla 2.18


(Reporter: kiko, Assigned: kiko)



(4 files, 1 obsolete file)

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

We've agreed on the basic interface, and I'm in the process of polishing it up
for submission.
OS: Linux → All
Hardware: PC → All
/me is amused that "standalone" and "written in Python" are in the description
together ;-) Presumably it doesn't stand alone from the Python interpreter?

Shiva, here's the bug-submission program I was telling you about.
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>
Assignee: myk → kiko
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.

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?
This is ready to be announced with the next Bugzilla point release.  I'll
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,
Attachment #132854 - Attachment mime type: application/octet-stream → text/plain
Attachment #132855 - Attachment mime type: application/octet-stream → text/plain
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.
Attachment #132855 - Attachment is obsolete: true
Attached patch README fileSplinter Review
My plan is to:

mkdir contrib/bug-bugzilla/

and check in the README, the script and the documentation (in all formats) into
this directory.
Requesting approval based on my plan.
Flags: approval?
Attached file Manual page in XML
Flags: approval? → approval+
Attached patch committed patchSplinter Review
For posterity.
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  <-- 
initial revision: 1.1
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/bug-bugzilla.xml,v  <--
initial revision: 1.1
/cvsroot/mozilla/webtools/bugzilla/contrib/bug-bugzilla/bugdata.txt,v  <-- 
initial revision: 1.1
Closed: 18 years ago
Resolution: --- → FIXED
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.

Gervaise, it's a program for bugging bugzilla about a bug.
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.)

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
> 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...)

Or, if you want it to start with "bug", then:

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.

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. :)
Target Milestone: --- → Bugzilla 2.18
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.