`report-emacs-bug' prompting rework

`report-emacs-bug' prompting rework

[Lars Ingebrigtsen]

As previously discussed (like, a year ago), the prompting sequence when
sending bug reports, especially from "emacs -Q", was kinda
unsatisfactory.  (The main point was that it required that you had a
valid-ish From header, even though you might end up sending the message
through mailclient.el, which will then just rewrite your From header,
anyway.)

Fixing this required a bit of refactoring of the sendmail.el/Message
setup functions, but hopefully I didn't screw up anything too badly.

And the prompting sequence looks OK to me now, but please let me know if
anything is wonky.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: `report-emacs-bug' prompting rework

[Ted Zlatanov]

On Fri, 10 Feb 2012 19:19:44 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> As previously discussed (like, a year ago), the prompting sequence when
LI> sending bug reports, especially from "emacs -Q", was kinda
LI> unsatisfactory.  (The main point was that it required that you had a
LI> valid-ish From header, even though you might end up sending the message
LI> through mailclient.el, which will then just rewrite your From header,
LI> anyway.)

LI> Fixing this required a bit of refactoring of the sendmail.el/Message
LI> setup functions, but hopefully I didn't screw up anything too badly.

LI> And the prompting sequence looks OK to me now, but please let me know if
LI> anything is wonky.

I still think Emacs bugs should be simply reported through a HTTP (REST
or whatever) call.  That would cover the most users and we can use
confirmation e-mails to avoid spamming.

Ted

Re: `report-emacs-bug' prompting rework

[Jason Rumney]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I still think Emacs bugs should be simply reported through a HTTP (REST
> or whatever) call.  That would cover the most users and we can use
> confirmation e-mails to avoid spamming.

A lot of users are behind a proxy.  You still have a configuration
nightmare to deal with.

Re: `report-emacs-bug' prompting rework

[Stephen J. Turnbull]

Jason Rumney writes:
 > Ted Zlatanov <tzz@lifelogs.com> writes:
 > 
 > > I still think Emacs bugs should be simply reported through a HTTP (REST
 > > or whatever) call.  That would cover the most users and we can use
 > > confirmation e-mails to avoid spamming.
 > 
 > A lot of users are behind a proxy.  You still have a configuration
 > nightmare to deal with.

Isn't this a Perl list?  Isn't "there's always more than one way to do
it" our motto?

Why can't we have both?

Re: `report-emacs-bug' prompting rework

[Ted Zlatanov]

On Sat, 11 Feb 2012 10:26:02 +0800 Jason Rumney <jasonr@gnu.org> wrote: 

JR> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I still think Emacs bugs should be simply reported through a HTTP (REST
>> or whatever) call.  That would cover the most users and we can use
>> confirmation e-mails to avoid spamming.

JR> A lot of users are behind a proxy.  You still have a configuration
JR> nightmare to deal with.

I think it's much harder to set up sendmail or SMTP.  Setting up a web
proxy is hardly a nightmare, and as I said it benefits a wide range of
users.  Specifically for submitting *Emacs bugs* it's a good solution.

On Sat, 11 Feb 2012 13:37:08 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Why can't we have both?

I'd love that: sendmail or SMTP for those who want it, and HTTP for
those who need it.

The web form would take some work for the confirmation e-mails, but
surely it would be worth it?  Would it help if I put it together?

Ted

Re: `report-emacs-bug' prompting rework

[Ted Zlatanov]

On Sat, 11 Feb 2012 09:31:22 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 11 Feb 2012 10:26:02 +0800 Jason Rumney <jasonr@gnu.org> wrote: 
JR> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I still think Emacs bugs should be simply reported through a HTTP (REST
>>> or whatever) call.  That would cover the most users and we can use
>>> confirmation e-mails to avoid spamming.

TZ> On Sat, 11 Feb 2012 13:37:08 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Why can't we have both?

TZ> I'd love that: sendmail or SMTP for those who want it, and HTTP for
TZ> those who need it.

TZ> The web form would take some work for the confirmation e-mails, but
TZ> surely it would be worth it?  Would it help if I put it together?

Ping?  Anyone interested in getting this going?

Ted

Re: `report-emacs-bug' prompting rework

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Ping?  Anyone interested in getting this going?

The main objection last time was that someone would have to maintain the
HTTP submitting interface somewhere on gnu.org, and nobody seemed
particularly thrilled by that task...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: `report-emacs-bug' prompting rework

[Ted Zlatanov]

On Mon, 13 Feb 2012 22:57:02 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Ping?  Anyone interested in getting this going?

LI> The main objection last time was that someone would have to maintain the
LI> HTTP submitting interface somewhere on gnu.org, and nobody seemed
LI> particularly thrilled by that task...

I said I'll write and maintain the... thingy.  It should be hosted on
FSF machines, though.  I don't want my servers to be a critical part of
the GNU Emacs project :)

It needs a machine with a web server that can do PHP, some kind of
persistence layer (MySQL, SQLite, etc.), and working outbound mail
service to the bugs mailing list.

I could use the GNU ELPA server, where I already have access.

Ted

Re: `report-emacs-bug' prompting rework

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 13 Feb 2012 22:57:02 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 
>
> LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> Ping?  Anyone interested in getting this going?
>
> LI> The main objection last time was that someone would have to maintain the
> LI> HTTP submitting interface somewhere on gnu.org, and nobody seemed
> LI> particularly thrilled by that task...
>
> I said I'll write and maintain the... thingy.  It should be hosted on
> FSF machines, though.  I don't want my servers to be a critical part of
> the GNU Emacs project :)
>
> It needs a machine with a web server that can do PHP, some kind of
> persistence layer (MySQL, SQLite, etc.), and working outbound mail
> service to the bugs mailing list.
>
> I could use the GNU ELPA server, where I already have access.

Please don't use the GNU ELPA server for this.

If you want to experiment, I suggest using your own server to begin
with; if we eventually decide to go this route (and I'm not committing
to anything), it is easy enough to migrate.

Note also that any revamp of the bug reporting system must be post-24.1.

Re: `report-emacs-bug' prompting rework

[Dimitri Fontaine]

Ted Zlatanov <tzz@lifelogs.com> writes:
> It needs a machine with a web server that can do PHP, some kind of
> persistence layer (MySQL, SQLite, etc.), and working outbound mail
> service to the bugs mailing list.

Sorry?  I think you might want to have a look at elnode.el and implement
that using Emacs and Emacs Lisp.  I though we had standards here :)

  http://www.emacswiki.org/emacs/Elnode
  https://github.com/nicferrier/elnode

Regards,
-- 
dim

Re: `report-emacs-bug' prompting rework

[Ted Zlatanov]

On Sun, 19 Feb 2012 14:05:37 +0100 Dimitri Fontaine <dim@tapoueh.org> wrote: 

DF> Ted Zlatanov <tzz@lifelogs.com> writes:
>> It needs a machine with a web server that can do PHP, some kind of
>> persistence layer (MySQL, SQLite, etc.), and working outbound mail
>> service to the bugs mailing list.

DF> Sorry?  I think you might want to have a look at elnode.el and implement
DF> that using Emacs and Emacs Lisp.  I though we had standards here :)

DF>   http://www.emacswiki.org/emacs/Elnode
DF>   https://github.com/nicferrier/elnode

I'll take a look, it looks interesting but pretty inconvenient to a sysadmin.

Ted