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.
/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>
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?
Created attachment 132854 [details] 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 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.
Created attachment 134531 [details] [diff] [review] 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.
Requesting approval based on my plan.
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
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. :)