Re: enhanced debian-changelog-mode.el
>>>>> "Chris" == Chris Waters <xtifr@dsp.net> writes:
Chris> karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes:
>> It would be good to have a mode that uses Gnus and/or W3 to
>> facilitate bug manipulation as well. I've thought only that it
>> should exist, and not much about how it ought to work. Any
>> ideas?
Chris> I'm a little dubious about Gnus, especially since some may
Chris> prefer VM or something. :-)
Ok... I don't know how you can use anything but Gnus if you're on
more than two or three mailing lists.
Chris> I'm really hoping that the bug system will be available
Chris> through LDAP someday soon. Failing that, I could probably
Chris> use HTTP (though I'd rather use it directly, rather than
Chris> depend on the presence of W3).
LDAP would be the ideal solution, I guess, at least for XEmacs >= 21,
since there's LDAP support built in. Is there such a thing for GNU
Emacs as well?
I don't know a lot about LDAP yet. If it gives a way to query the
BTS database selectively, then I suppose it would work VERY well for
a control panel sort of interface.
>> The email approach would have the advantage over CGI that it
>> would work while offline. You could ask it to retrieve the
>> summary information, wait by the mailbox until it comes in,
>> then hang up the line.
Chris> Kind of annoying to have emacs sitting there waiting for an
Chris> arbitrary email to come in. Especially if you're offline.
Well, I wouldn't design it to sit there and wait. It would send off
an email and return to the command loop. You'd then have to go to
your Gnus *Groups* buffer, hit `g', and then open the folder where
your bug stuff lands... when you open the mail message, it would go
into the mode and you could work with it.
It sounds really kludgey now. I'd spend more time hammering on bugs
than actually working with bug reports...
Chris> To be really useful, interactively, you want something
Chris> available at a socket layer, like LDAP or HTTP. Which
Chris> won't work offline, but then, you really can't do
Chris> interactive stuff with the BTS unless you have access to
Chris> the BTS....
Hmmm. Interactive, then as a fallback, use email? If it could send
a query to the BTS, via HTTP or email, you could stow that
someplace... I guess in parsed form would be best... and use THAT
offline. The interactive mode would work better though...
Chris> What I'm thinking of is something like: you press C-c C-b
Chris> (`b' for "bug closer"), and it asks you for the bug number.
Chris> If you press `?', it tries to browse the bugs for that
Chris> package, and, if it can't access the BTS, then it tells you
Chris> that, and you decide whether you just want to enter a
Chris> number manually or abort. Obviously, for something like
Chris> that, email is not a reasonable option.
Email might work if the BTS sent something parsable and you'd request
it, async, then when it came in, piped it (manually or with procmail)
through a parser that stowed the lisp-readable table in a cache. I
seem to recall folks "over there" saying they pay for phone line
time, so an email based or at least cacheing backend for this would
be really cool to have. You could have the similar effect without
the wait for an email to return by having it use LDAP or HTTP, then
cache that data. When online, the remote BTS control could happen
interactively, and when offline, our program could generate email
control messages, send them via the local mail-to-the-net agent,
which might queue them until the next time the line comes up.
It would work like a checkbook register. You track what you do, then
reconcile it with the BTS once in a while, to bring in new reports
and whatnot.
A collapsible control-panel type of interface would be neat. You
could call it from the changelog mode like that, then click on one or
several bugs (with checkboxes by them) to close them. It would be
good to be able to check off several bugs to merge, then just click
or press enter over a [Merge] button, and have it automagicly tell
the BTS server to merge them... either via a realtime protocol, or
via autogenerated and emailed control messages.
When you change a bugs title, after you select that operation from a
mode menu on the far button, that bug reports title could turn into
an editable text widget. You'd edit and press `done'... it could
work something like how `M-x customize' does.
The bugs would be displayed as number and title, I suppose, with an
expandit button that shows the bodies of the messages... maybe you'd
read/reply in something like an email reader, if not actually an
email reader. If it used regular mailbox files, it would work in any
email reader, I guess. VM is very nice, and I bet it works well for
this sort of thing.
Chris> But this is a long way from being working code in any case.
Chris> :-)
Working code doesn't happen without forming some idea of what the
program needs to do. I know the language some now, but need
something to say in it to prove that.
Let's plan this thing out, and when there's time and the plan is
right, we'll build it! I would enjoy learning the software
architecture planning process... I'll listen more than I say, I
imagine... (some of what I "hear" I'll type down.)
Obviously on the study for this list would be `ldap', `http', `w3',
`eudc', and the BTS. `cookie' might be good for the interface,
unless `w3' proves nicer and useable/understandable enough. (It's
table layout might make for nicer looking control panels.) What
else?
Reply to: