Provide standalone bug submission program

RESOLVED FIXED in Bugzilla 2.18

Status

()

defect
RESOLVED FIXED
16 years ago
7 years ago

People

(Reporter: kiko, Assigned: kiko)

Tracking

2.17.4
Bugzilla 2.18
Bug Flags:
approval +

Details

Attachments

(4 attachments, 1 obsolete attachment)

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

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

Gerv
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
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,
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
Posted 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.
Status: NEW → ASSIGNED
Flags: approval?
Posted file Manual page in XML
Flags: approval? → approval+
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  <-- 
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
Status: ASSIGNED → RESOLVED
Closed: 16 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.

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

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