(I've Cc'd redhat-devel to move the conversation over to
there. Please remove pinstripe from the To and CC headers in any
replies)
On Wed, 16 Aug 2000, John Summerfield wrote:
>> So that is at least 3 people here liking the idea now. Looks
>> good to me. What is your prefered interface? Mine is color text
>> mode, ncurses/slang. Anyone else?
>
>I find colours that wokr on yer basic Linux console are next to impossible to
>read in any kind of xterm window.
Well, of course mono support would be a must too..
>Inverse video is woeful too; I have great difficulty with lynx on that
>account.
Sure.. it would be compatible with mono and color of course. I
wouldn't necessarily write all that stuff, but it wouldn't be
difficult for someone else to do.
>Presumably most of us can cope with a browser interface. It shouldn't be too
>hard for RHL to install with bugzilla+ all ready to receive and forward bugs.
No thanks. An optional browser interface perhaps. I prefer a
real app to a thin client browser thingie. Again, it could be a
frontend though. Like linuxconf for example: commandline,
ncurses,web, X...
>If that's not popular (I ALYAYS install apache, but maybe
>others don't like to have it), something in TCL should be easy
>for someone who understands it to put together. Or one of the
>gtk toolkits. Or Java.
Relying on tonnes of external stuff being installed for a bug
reporting app is asking for a smaller list of bug reports. TCL
should be burned off the face of the earth IMHO... but that is
just because 99% of all TCL apps crash horribly or are incredibly
slow and crash, or crash and are incredibly slow, and stay
running in memory in the background without you knowing. ;o)
If I wrote such a beast, it would be straight C, with an API to
plugin various frontends to such as discussed above. That way it
works everywhere. You install the frontend for your prefered
environment. No reliance on perl/tcl/tk/python or whatever...
>Just so long as the software to run it's on the CD.
Yes, the frontends could be written in anything, but there should
be a C ncurses frontend minimum as most people can run that,
either at the console, in Xterm, or otherwise. If need be, a
oldfashioned question-response script kindof thing could be the
lowest common denominator. Something like the options available
in the kernel config process...
>> It would be best if such app talked either HTTP to the bugzilla
>> pages, or in case the chance that the pages change in any
>> significant way, a bugzilla server app perhaps? Any other
>
>If it uses http, it can't be sure of getting my email address right.
If I write it, it wont be doing anything behind your back. It
will need to be configured properly first, and it will ask you
for your email address, perhaps attempting to guess first by
looking at your local hostname, username, perhaps inside .pinerc,
or whatnot... It would allow you to decide though.
>Unless there'sa good reason to use http, don't. You could
>always prepare a datastream for a post, then mail it as an
>attachment. Something at the bugzilla end reads the mail and
>files the attachment.
Does bugzilla have an alternate interface than http? If I were
writing a client side frontend, I wouldn't be writing a bug
reporting backend to replace bugzilla. If bugzilla uses http
only, then http it is. I don't see any problem. I like the mail
idea too though.
>If RHI is using an sql database, it shouldn't be hard to prepare and submit an
>sql statement.
Keep in mind the security aspects of this too. Submitting email
to the thing needs to be secure. People could submit cron jobs
or /fat32/autoexec.bat as a bug report directly. How would the
server side handle it? How would authentication be done via
email? With HTTP you have to log in. With email you have a
sink. A sink open to spam and a horde of other things. It is
possible but would have to be done carefully...
>Or maybe it should go dressed up as xml; that seems to be in
>fashion right now.
Ugg. Perhaps... The phrase "XML" is sounding more and more like
the word "millenium" to me every day... getting sick of it. ;o)
>> thoughts? Lets brainstorm this one out fully. Get some decent
>> feedback going here, and plan out an application. I'm sure it
>> will be received well. Perhaps it should be moved to
>> redhat-devel though..
>
>We're here now;-)
This is pinstripe-list... I suppose the topic is relevant
partially, but discussing development of a new program seems to
fit redhat-devel better, so I've Cc'd that list, and will remove
pinstripe from replies.
>> >Potentially, the information would be better than bugzilla gets now.
>>
>> I agree fully with that too. I've planned on writing some kind
>> of bug report app for quite some time. I do something in KDE, it
>
>KDE's fine.
No I meant "when I use KDE", not I'll write a front-end for
KDE. Uggh... C++ programming.. no thanks.. ;o)
>Or text-mode with GNOME & KDE wrappers. Someone can do other interfaces if
>they like.
Yes, that is my preference. If I start it up, it will be cleanly
coded C. Either with an ncurses or slang text interface, or a
GTK interface to start with. Of course, it would be open from
the start, so others could start other interfaces as well at the
same time...
>> Who all is interested out there in taking on a project to provide
>> a front end to bugzilla? If there are enough people, perhaps
>> I'll start a new opensource project on source forge. I guarantee
>> it WONT be called "bug pal" or anything anal retentive like
>> that.. ;o)
>
>bugger.
Heheh. That word has different meanings in North America, and
Britain. ;o)
If the text interface is "bugreporter", I'll assure that the GTK
version won't suffer from the common "gbugreporter" braindamaged
naming convention. ;o) I'm more inventive than that. Something
like "gtkbugreporter". Hahaha. Just kidding! ;o)
"crashomatic"? ;o)
...
TTYL
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
