From @demerphq

Created by @demerphq

We make it unnecessarily complicated to file bug reports on rt.perl.org,
especially by committers.

It seems ridiculous that I can close *every* bug in rt.perl.org if I
wanted but I cannot *create* one without running the perlbug utility.

perlbug is really old tech, and for people that use things like gmail
it just makes the process unnecessarily cumbersome and stupid. You have
to run perlbug, enter in a bunch of stuff, launch a text editor, type,
then do some more silly command line options. At which point you have
to cat the produced document, copy and paste it into your gmail editor,
remove half the stuff that you had to enter in during previous steps
(becuase they are headers) and then finally send the mail.

IMO it is really silly to expect normal users to do this, and seriously
insane that committers who can close bugs, push patches, etc, in 2010
style, then have to fall back to 1980's technology to create a ticket.

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

But even if we decide that this is a step too far for the general public
I think there is absolutely no justification for requiring committers to
jump through these hoops. Our time is extremely valuable to the project
and it should not be wasted with such bullshit makework.

Frankly this just pisses me off. This state of affairs has persisted for far
too long and has no justification whatsoever.

Flags:
    category=utilities
    severity=wishlist

Site configuration information for perl 5.17.9:

Configured by yorton at Thu Feb  7 16:15:15 CET 2013.

Summary of my perl5 (revision 5 version 17 subversion 9) configuration:
  Derived from: 048b63be58b8721f0571d952bfb6e6194e154942
  Platform:
    osname=linux, osvers=3.0.0-12-generic, archname=x86_64-linux
    uname='linux yam 3.0.0-12-generic #20-ubuntu smp fri oct 7
14:56:25 utc 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Doptimize=-g -d -Dusedevel -Dcc=ccache gcc -Dld=gcc
-DDEBUGGING'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
    ccversion='', gccversion='4.6.1', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib
/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib
-fstack-protector'

Locally applied patches:



@INC for perl 5.17.9:
    lib
    /usr/local/lib/perl5/site_perl/5.17.9/x86_64-linux
    /usr/local/lib/perl5/site_perl/5.17.9
    /usr/local/lib/perl5/5.17.9/x86_64-linux
    /usr/local/lib/perl5/5.17.9
    .


Environment for perl 5.17.9:
    HOME=/home/yorton
    LANG=en_US.UTF-8
    LANGUAGE=en
    LC_COLLATE=en_US.UTF-8
    LC_CTYPE=en_US.UTF-8
    LC_MESSAGES=en_US.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/yorton/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From alex.hartmaier@gmail.com

On Fri, Feb 8, 2013 at 5​:25 AM, yves orton <perlbug-followup@​perl.org>wrote​:

# New Ticket Created by yves orton
# Please include the string​: [perl #116685]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=116685 >

This is a bug report for perl from demerphq@​gmail.com,
generated with the help of perlbug 1.39 running under perl 5.17.9.

-----------------------------------------------------------------
[Please describe your issue here]

We make it unnecessarily complicated to file bug reports on rt.perl.org,
especially by committers.

It seems ridiculous that I can close *every* bug in rt.perl.org if I
wanted but I cannot *create* one without running the perlbug utility.

perlbug is really old tech, and for people that use things like gmail
it just makes the process unnecessarily cumbersome and stupid. You have
to run perlbug, enter in a bunch of stuff, launch a text editor, type,
then do some more silly command line options. At which point you have
to cat the produced document, copy and paste it into your gmail editor,
remove half the stuff that you had to enter in during previous steps
(becuase they are headers) and then finally send the mail.

IMO it is really silly to expect normal users to do this, and seriously
insane that committers who can close bugs, push patches, etc, in 2010
style, then have to fall back to 1980's technology to create a ticket.

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

But even if we decide that this is a step too far for the general public
I think there is absolutely no justification for requiring committers to
jump through these hoops. Our time is extremely valuable to the project
and it should not be wasted with such bullshit makework.

Frankly this just pisses me off. This state of affairs has persisted for
far
too long and has no justification whatsoever.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=utilities
severity=wishlist
---
Site configuration information for perl 5.17.9​:

Configured by yorton at Thu Feb 7 16​:15​:15 CET 2013.

Summary of my perl5 (revision 5 version 17 subversion 9) configuration​:
Derived from​: 048b63b
Platform​:
osname=linux, osvers=3.0.0-12-generic, archname=x86_64-linux
uname='linux yam 3.0.0-12-generic #20-ubuntu smp fri oct 7
14​:56​:25 utc 2011 x86_64 x86_64 x86_64 gnulinux '
config_args='-Doptimize=-g -d -Dusedevel -Dcc=ccache gcc -Dld=gcc
-DDEBUGGING'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler​:
cc='ccache gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-g',
cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
ccversion='', gccversion='4.6.1', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries​:
ld='gcc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib
/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.13'
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib
-fstack-protector'

Locally applied patches​:

---
@​INC for perl 5.17.9​:
lib
/usr/local/lib/perl5/site_perl/5.17.9/x86_64-linux
/usr/local/lib/perl5/site_perl/5.17.9
/usr/local/lib/perl5/5.17.9/x86_64-linux
/usr/local/lib/perl5/5.17.9
.

---
Environment for perl 5.17.9​:
HOME=/home/yorton
LANG=en_US.UTF-8
LANGUAGE=en
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/home/yorton/bin​:/usr/lib/lightdm/lightdm​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/usr/bin​:/sbin​:/bin​:/usr/games
PERL_BADLANG (unset)
SHELL=/bin/bash

+1
when I commited the first draft of my perlopentut modernization it took me
over an hour to find out how to do it and in the end had the same problems
as you because my box isn't set up for sending mail through smtp.
There should be an option if you're online (the http post), one to store it
to a file for later submission and one for submitting manually.

The RT System itself - Status changed from 'new' to 'open'

From @Leont

On Fri, Feb 8, 2013 at 5​:25 AM, yves orton <perlbug-followup@​perl.org> wrote​:

perlbug is really old tech, and for people that use things like gmail
it just makes the process unnecessarily cumbersome and stupid. You have
to run perlbug, enter in a bunch of stuff, launch a text editor, type,
then do some more silly command line options. At which point you have
to cat the produced document, copy and paste it into your gmail editor,
remove half the stuff that you had to enter in during previous steps
(becuase they are headers) and then finally send the mail.

That's pretty much my workflow too.

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

Yes please.

But even if we decide that this is a step too far for the general public
I think there is absolutely no justification for requiring committers to
jump through these hoops. Our time is extremely valuable to the project
and it should not be wasted with such bullshit makework.

I agree.

Leon

From castaway@desert-island.me.uk

On Fri, 08 Feb 2013 04​:25​:53 -0000, yves orton <perlbug-followup@​perl.org>
wrote​:

# New Ticket Created by yves orton
# Please include the string​: [perl #116685]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=116685 >

We make it unnecessarily complicated to file bug reports on rt.perl.org,
especially by committers.

It seems ridiculous that I can close *every* bug in rt.perl.org if I
wanted but I cannot *create* one without running the perlbug utility.

perlbug is really old tech, and for people that use things like gmail
it just makes the process unnecessarily cumbersome and stupid. You have
to run perlbug, enter in a bunch of stuff, launch a text editor, type,
then do some more silly command line options. At which point you have
to cat the produced document, copy and paste it into your gmail editor,
remove half the stuff that you had to enter in during previous steps
(becuase they are headers) and then finally send the mail.

I've just done one of these. By "half the stuff" I assume you mean the top
five lines which are the Reply-To, Message-ID, Subject, To and From
headers?

IMO it is really silly to expect normal users to do this, and seriously
insane that committers who can close bugs, push patches, etc, in 2010
style, then have to fall back to 1980's technology to create a ticket.

I do agree, especially if you don't run a local SMTP (and I do, but I
wanted to add a file attachment, so I still had to jump through the hoops)

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

This would require work on the RT instance I assume?

But even if we decide that this is a step too far for the general public
I think there is absolutely no justification for requiring committers to
jump through these hoops. Our time is extremely valuable to the project
and it should not be wasted with such bullshit makework.

Frankly this just pisses me off. This state of affairs has persisted for
far
too long and has no justification whatsoever.

After a bit of random thinking, I came up with a (probably) easier to
implement solution that solves your particular issue without changing the
RT instance, Update perlbug to be able to create a Draft email on an IMAP
server. I've done a minor bit of research, and it appears that doing this
for a gmail account isn't *too* hard.

So the idea is​:
1) perlbug asks if you would like to submit via IMAP (or just gmail since
thats common)
2) it checks if you've previously oauthed (~/.perlbug or something)
3) if not then it gives you a url to copy, and asks for the resulting PIN
code (or similar)
4) stores the access token from the above for future use
5) when complete creates a message in your Draft folder containing the
correct headers/content

All you then have to do is a short review and hit send. perlbug could even
do that if you prefer hands off.

I'm also tempted to support adding file attachments.

Jess

From trs@bestpractical.com

On 02/08/2013 06​:06 AM, Jess Robinson wrote​:

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

This would require work on the RT instance I assume?

There are a number of existing ways to create tickets from outside RT.
Depending on your authentication requirements, there may need to be some
slight configuration tweaks, but I doubt any real work. (This is
written with not much, but some, knowledge about rt.perl.org specifically.)

After a bit of random thinking, I came up with a (probably) easier to
implement solution that solves your particular issue without changing
the RT instance, Update perlbug to be able to create a Draft email on an
IMAP server. I've done a minor bit of research, and it appears that
doing this for a gmail account isn't *too* hard.

For committers and patch writers, don't bother adding this to perlbug​:
just pipe the perlbug output to git-imap-send. The man page even
includes an example for gmail's drafts folder.

Thomas

From @demerphq

On 8 February 2013 18​:03, Thomas Sibley <trs@​bestpractical.com> wrote​:

On 02/08/2013 06​:06 AM, Jess Robinson wrote​:

I really think we should generally fix this, so that all users can file
a bug report without needing to do all this, even making perlbug submit
its ticket via a web POST request.

This would require work on the RT instance I assume?

There are a number of existing ways to create tickets from outside RT.
Depending on your authentication requirements, there may need to be some
slight configuration tweaks, but I doubt any real work. (This is
written with not much, but some, knowledge about rt.perl.org specifically.)

Just to be clear, what I really want is the ability to create the
ticket in rt.perl.org just like I can in rt.cpan.org.

After a bit of random thinking, I came up with a (probably) easier to
implement solution that solves your particular issue without changing
the RT instance, Update perlbug to be able to create a Draft email on an
IMAP server. I've done a minor bit of research, and it appears that
doing this for a gmail account isn't *too* hard.

For committers and patch writers, don't bother adding this to perlbug​:
just pipe the perlbug output to git-imap-send. The man page even
includes an example for gmail's drafts folder.

Ah, that is interesting, it would make things a little easier for sure. Thanks.

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

I am responsible enough to enter the required meta-data, and IMO
generally the information in a perlbug ticket that comes from blead is
not that relevant really. Heck the perlbug might be running on a Perl
that has locally committed patches, and etc, which may and probably is
totally irrelevant to the bug being reported.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From trs@bestpractical.com

On 02/08/2013 09​:22 AM, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

This is not a technical problem, but an rt.perl.org and p5p policy
decision. I'm not in a position to change that myself.

It is quite possible to give only committers access to create tickets on
rt.perl.org directly, and funnel everyone else through perlbug. Likely
not the best solution, but a solution nonetheless.

I am responsible enough to enter the required meta-data, and IMO
generally the information in a perlbug ticket that comes from blead is
not that relevant really. Heck the perlbug might be running on a Perl
that has locally committed patches, and etc, which may and probably is
totally irrelevant to the bug being reported.

Other projects generally stall/reject tickets if they're reported
without enough diagnostics or the reporter doesn't later provide the
necessary diagnostics upon request.

This strategy lets tickets be opened more freely, but still allows for
clear cases of "diagnostics or it didn't happen."

Thomas

From @demerphq

On 8 February 2013 18​:29, Thomas Sibley <trs@​bestpractical.com> wrote​:

On 02/08/2013 09​:22 AM, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

This is not a technical problem, but an rt.perl.org and p5p policy
decision. I'm not in a position to change that myself.

Thanks, thats exactly what I expected and wanted to know.

I was asking so I would know if it should be trivial for the
maintainer to allow this.

It is quite possible to give only committers access to create tickets on
rt.perl.org directly, and funnel everyone else through perlbug. Likely
not the best solution, but a solution nonetheless.

From my point of view as a committer it would make things a lot
easier. As I said earlier, I have permissions to close every bug in
rt.perl.org, yet I cant create one by jumping through hoops.

I am responsible enough to enter the required meta-data, and IMO
generally the information in a perlbug ticket that comes from blead is
not that relevant really. Heck the perlbug might be running on a Perl
that has locally committed patches, and etc, which may and probably is
totally irrelevant to the bug being reported.

Other projects generally stall/reject tickets if they're reported
without enough diagnostics or the reporter doesn't later provide the
necessary diagnostics upon request.

Sure, and as a committer I know exactly what needs to be in a ticket
or not. After all, I am one of the people that would be responsible
for marking the ticket as stalled.

This strategy lets tickets be opened more freely, but still allows for
clear cases of "diagnostics or it didn't happen."

For the kinds of things I need to report about the only useful thing
to report is the version.

Thanks for your explanations,

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @bulk88

On Fri Feb 08 09​:22​:51 2013, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

So what happens to people who can't close tickets? perlbug and copy pasting?

I am responsible enough to enter the required meta-data, and IMO
generally the information in a perlbug ticket that comes from blead is
not that relevant really. Heck the perlbug might be running on a Perl
that has locally committed patches, and etc, which may and probably is
totally irrelevant to the bug being reported.

You can send an email without perlbug data to Perl RT and if you pass
the spam filter you get a ticket (that is the biggest problem, if the
email has perlbug data is it whitelisted, if it doesn't, 30% chance in
my experience of it being blocked).

perlbug should be fixed to either understand modern smtp directly (most
webmail providers nowadays have SMTP/POP3), or POST it to RT.

--
bulk88 ~ bulk88 at hotmail.com

From @rjbs

* demerphq <demerphq@​gmail.com> [2013-02-08T12​:38​:06]

On 8 February 2013 18​:29, Thomas Sibley <trs@​bestpractical.com> wrote​:

On 02/08/2013 09​:22 AM, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

This is not a technical problem, but an rt.perl.org and p5p policy
decision. I'm not in a position to change that myself.

Thanks, thats exactly what I expected and wanted to know.

Also, it's one that I'd like to fix, absolutely.

Right now, Best Practical is working on upgrading rt.perl.org to a modern RT
version. They've assured me that we are not getting their scrap time, but
that they are treating us they same as they treat any paying customer. The new
RT update has been beta-tested by some heavy users of rt.perl.org, and should
be ready in not too long, as I understand it.

I asked about enabling users to create tickets some time ago, and the answer
was, basically, "It should be easy to allow, of course, but the way that the
old rt.perl.org was customized has made it difficult to fix."

Making it possible for *at least* committers to create tickets w/o using
perlbug is definitely something that we want to happen.

I also want to improve the situation for non-committers. The key issue is
*strongly* encouraging users to include `perl -V`. I agree that forcing users
to use perlbug is too strong a tonic for this problem.

One thing we've talked about in the past is having `perlbug` able to open up a
local HTML document that will submit to the RT instance, with things like
perl-V output prefilled.

In the end, for now, you can simply send mail to perlbug@​perl.org. Make sure
you mention perl in it, or it is likely to be eaten by the filters.

--
rjbs

From @demerphq

On 8 February 2013 19​:13, bulk88 via RT <perlbug-followup@​perl.org> wrote​:

On Fri Feb 08 09​:22​:51 2013, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

So what happens to people who can't close tickets? perlbug and copy pasting?

Preferably they could do the same as a committer, my point of
discussing committers was that it hopefully bypassed any arguments
about people filing bogus reports without critical details. The
assumption being if we are responsible enough to commit and close
tickets we should be responsible enough to file useful bugs.

I am responsible enough to enter the required meta-data, and IMO
generally the information in a perlbug ticket that comes from blead is
not that relevant really. Heck the perlbug might be running on a Perl
that has locally committed patches, and etc, which may and probably is
totally irrelevant to the bug being reported.

You can send an email without perlbug data to Perl RT and if you pass
the spam filter you get a ticket (that is the biggest problem, if the
email has perlbug data is it whitelisted, if it doesn't, 30% chance in
my experience of it being blocked).

perlbug should be fixed to either understand modern smtp directly (most
webmail providers nowadays have SMTP/POP3), or POST it to RT.

Indeed. And as I recall in the win32 world having a local SMTP server
is pretty common. (At least it was for me back when I was a windows
guy.)

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @demerphq

On 8 February 2013 19​:23, Ricardo Signes <perl.p5p@​rjbs.manxome.org> wrote​:

* demerphq <demerphq@​gmail.com> [2013-02-08T12​:38​:06]

On 8 February 2013 18​:29, Thomas Sibley <trs@​bestpractical.com> wrote​:

On 02/08/2013 09​:22 AM, demerphq wrote​:

But please, if you know how to enable rt.perl.org to allow people who
can close tickets to open them that is what I would prefer the most.

This is not a technical problem, but an rt.perl.org and p5p policy
decision. I'm not in a position to change that myself.

Thanks, thats exactly what I expected and wanted to know.

Also, it's one that I'd like to fix, absolutely.

Great. Thanks.

Right now, Best Practical is working on upgrading rt.perl.org to a modern RT
version. They've assured me that we are not getting their scrap time, but
that they are treating us they same as they treat any paying customer. The new
RT update has been beta-tested by some heavy users of rt.perl.org, and should
be ready in not too long, as I understand it.

That sounds very promising.

I asked about enabling users to create tickets some time ago, and the answer
was, basically, "It should be easy to allow, of course, but the way that the
old rt.perl.org was customized has made it difficult to fix."

Ah, ok. Thanks, it makes it a little less frustrating to know the cause.

Making it possible for *at least* committers to create tickets w/o using
perlbug is definitely something that we want to happen.

I also want to improve the situation for non-committers. The key issue is
*strongly* encouraging users to include `perl -V`. I agree that forcing users
to use perlbug is too strong a tonic for this problem.

Sounds all good.

One thing we've talked about in the past is having `perlbug` able to open up a
local HTML document that will submit to the RT instance, with things like
perl-V output prefilled.

In the end, for now, you can simply send mail to perlbug@​perl.org. Make sure
you mention perl in it, or it is likely to be eaten by the filters.

Ah, that is very useful advice. Thanks.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

From @ap

* yves orton <perlbug-followup@​perl.org> [2013-02-08 05​:30]​:

perlbug is really old tech, and for people that use things like gmail
it just makes the process unnecessarily cumbersome and stupid. You
have to run perlbug, enter in a bunch of stuff, launch a text editor,
type, then do some more silly command line options. At which point you
have to cat the produced document, copy and paste it into your gmail
editor, remove half the stuff that you had to enter in during previous
steps (becuase they are headers) and then finally send the mail.

Maybe there should be a utility that just spits out a report template
with all the relevant diagnostics filled in, like perlbug’s output is
now, but without any interactive prompts and no attempt whatsoever to
send mail? Then just leave it to the user whether they want to pipe it
into mutt or paste it into Gmail or whatever. Maybe save the template
to a file and output a few readily copy-pasteable example command lines
for mutt etc to the console, plus instructions for Gmail.

From @jkeenan

On Thu Feb 07 20​:25​:53 2013, demerphq wrote​:

This is a bug report for perl from demerphq@​gmail.com,
generated with the help of perlbug 1.39 running under perl 5.17.9.

-----------------------------------------------------------------
[Please describe your issue here]

We make it unnecessarily complicated to file bug reports on
rt.perl.org,
especially by committers.

It seems ridiculous that I can close *every* bug in rt.perl.org if I
wanted but I cannot *create* one without running the perlbug utility.

This very old RT ticket,
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=20505, may be relevant to
the discussion in this thread.