[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: