perl debugger not keeping history as documented

[p5pRT]

Migrated from rt.perl.org#118187 (status was 'rejected')

Searchable as RT118187$

[p5pRT]

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I was thinking about adding a history file to the perl debugger when I find it is already supposed to support one.

I tried it -- it did find my options file\, in it I put​: parse_options("HistSize=1000 HistFile=/home/law/.perl5db.hist");

Initially it complained about permissions on the file claiming only I should have access -- which is the case\, I'm in my own group\, so my group has write perms as well. So many progs assume they know your security policy better than you do... (sendmail\, ssh\, to name a few).

That aside\, I fixed that\, (chmod g-w file) and the warning went away.

From this I assume it read the options file and didn't complain about its content.

So I started up the debugger and press 's' a few times in a program. I then hit 'q'\, then entered again -- nothing had been stored.

So... wazzup? Isn't this supposed to work?

It's really needed\, since much of the time\, whatever I'm debugging has killed the debugger (either by itself\, or by me having to kill perl). Having it save all my debugging commands would be a blessing for my weary\, overused fingers...

Shouldn't this work?...

Tnx.

Perl Info

``` Flags: category=core severity=medium This perlbug was built using Perl 5.16.2 - Fri Feb 15 01:17:37 UTC 2013 It is being executed now by Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013. Site configuration information for perl 5.16.2: Configured by abuild at Fri Feb 15 01:12:05 UTC 2013. Summary of my perl5 (revision 5 version 16 subversion 2) configuration: Platform: osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', 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='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.16.2: /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.2 /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/5.16.2 /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/site_perl . Environment for perl 5.16.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib64/mpi/gcc/openmpi/lib64 LOGDIR (unset) PATH=.:/home/law/bin/lib:/sbin:/usr/local/sbin:/usr/lib64/mpi/gcc/openmpi/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL5OPT=-CSA -I/home/law/bin/lib PERLDB_HIST=/home/law/.perl5db.hist PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @shlomif

Hi Linda (and all)\,

On Sun May 26 12​:43​:57 2013\, LAWalsh wrote​:

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.39 running under perl 5.16.2.

----------------------------------------------------------------- [Please describe your issue here] I was thinking about adding a history file to the perl debugger when I find it is already supposed to support one.

I tried it -- it did find my options file\, in it I put​: parse_options("HistSize=1000 HistFile=/home/law/.perl5db.hist");

Initially it complained about permissions on the file claiming only I should have access -- which is the case\, I'm in my own group\, so my group has write perms as well. So many progs assume they know your security policy better than you do... (sendmail\, ssh\, to name a few).

That aside\, I fixed that\, (chmod g-w file) and the warning went away.

From this I assume it read the options file and didn't complain about its content.

So I started up the debugger and press 's' a few times in a program. I then hit 'q'\, then entered again -- nothing had been stored.

So... wazzup? Isn't this supposed to work?

By design\, the debugger does not store one-character-long commands in the history - only those that are two characters'-or-more long. Here is the code for that in the bleadperl debugger​:

  # Empty input means repeat the last command.   if ($cmd eq '') {   $cmd = $laststep;   }   chomp($cmd); # get rid of the annoying extra newline   if (length($cmd) >= 2) {   push( @​hist\, $cmd );   }   push( @​truehist\, $cmd );   share(@​hist);   share(@​truehist);

  # This is a restart point for commands that didn't arrive   # via direct user input. It allows us to 'redo PIPE' to   # re-execute command processing without reading a new command.

Please try recalling longer commands.

Lots of debugger activity the past few days. :-)

Regards\,

-- Shlomi Fish

[p5pRT]

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

[p5pRT]

From perl-diddler@tlinx.org

Hmmm... you are right... longer ones worked.

Not a big deal\, but I sorta like the feature in bash not to record successive duplicate lines...but that could easily be a whim.

Thanks for point this out\, though it seems a bit arbitrary.

Nevermind... ;-) (closing)...

[p5pRT]

From perl-diddler@tlinx.org

On Sun May 26 14​:45​:14 2013\, LAWalsh wrote​:

Hmmm... you are right... longer ones worked.

Not a big deal\, but I sorta like the feature in bash not to record successive duplicate lines...but that could easily be a whim.

Thanks for point this out\, though it seems a bit arbitrary.

Nevermind... ;-) (closing)... Guess I'm not allowed to close out my own bugs either...

What's up w/that? I.e. is there a professional reason for that\, or is this just more power play games?? (Which others have pointed out was the real reason for me being tossed off list\, since what I actually posted was pretty innocuous (guess it pushed some buttons).

[p5pRT]

From @tonycoz

On Sun May 26 14​:48​:15 2013\, LAWalsh wrote​:

(closing)... Guess I'm not allowed to close out my own bugs either...

I've closed it.

Tony

[p5pRT]

@tonycoz - Status changed from 'open' to 'rejected'

[p5pRT]

From @karenetheridge

On Sun\, May 26\, 2013 at 02​:48​:16PM -0700\, Linda Walsh via RT wrote​:

What's up w/that? I.e. is there a professional reason for that\, or is this just more power play games?? (Which others have pointed out was the real reason for me being tossed off list\, since what I actually posted was pretty innocuous (guess it pushed some buttons).

That wasn't "power play games"\, it was a response to rudeness (yours). And you were just rude again.

--   "Whereof we cannot speak\, thereof we must be silent." - Ludwig Wittgenstein   . . . . . Karen Etheridge\, karen@​etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++

[p5pRT]

From perl-diddler@tlinx.org

On Mon May 27 12​:44​:12 2013\, perl@​froods.org wrote​:

On Sun\, May 26\, 2013 at 02​:48​:16PM -0700\, Linda Walsh via RT wrote​:

What's up w/that? I.e. is there a professional reason for that\, or is this just more power play games?? (Which others have pointed out was the real reason for me being tossed off list\, since what I actually posted was pretty innocuous (guess it pushed some buttons).

That wasn't "power play games"\, it was a response to rudeness (yours). And you were just rude again.

---

Rather than just demonstrating your rudeness\, would you care to show me exactly what rude event caused the removal of my ability to reopen or close my own bugs.

If not\, consider how you\, sitting in a position of the coddled and protected\, are able to made rude comments to someone because it is the in thing to do.

If it was about interpersonal rudeness\, then it would have been dealt with on that level by people just putting me in a killfile. Instead\, top level administrative power had to be used to silence -- it wasn't about the interpersonal. It was about me having dangerous ideas that had to be peremptorily silenced. I'm familiar with the tactic.

As for common rudeness being a problem on the p5p list? I've never been on a list that specifically is described as having a "for people interested in Perl5 core development​: High volume and **temperature** rating." Having the list described by the official website as high temperature rating was there long before I came on the list.

[p5pRT]

From @Leont

On Mon\, May 27\, 2013 at 10​:11 PM\, Linda Walsh via RT \perlbug\-followup@​perl\.org wrote​:

Rather than just demonstrating your rudeness\, would you care to show me exactly what rude event caused the removal of my ability to reopen or close my own bugs.

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.

If it was about interpersonal rudeness\, then it would have been dealt with on that level by people just putting me in a killfile. Instead\, top level administrative power had to be used to silence -- it wasn't about the interpersonal.

It was done after the "top level administrative power" got a series of complaints about your behavior on the list\, and after you have been asked multiple times to change your behavior.

As for common rudeness being a problem on the p5p list? I've never been on a list that specifically is described as having a "for people interested in Perl5 core development​: High volume and **temperature** rating." Having the list described by the official website as high temperature rating was there long before I came on the list.

That's no excuse.

Leon

[p5pRT]

From perl-diddler@tlinx.org

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.

---

So until about 2-3 weeks from several years back\, I was special\, but now I'm not. You may be speaking in all honest\, but the timing is more than a little coincidental. Considering it hadn't been a problem for years then was taken away when I tried to reopen a bug originally against 5.10 or 12\, but didn't seem to hit the right switches ended up filing a 2nd bug against 5.16.

It was done after the "top level administrative power" got a series of complaints about your behavior on the list\, and after you have been asked multiple times to change your behavior.

---

My behavior wasn't at issue. It was my political views regarding perl. My behavior was no worse than anyone who attacked me\, just that I had alot of detractors. The fact that any official body would step in and give over to the children what they wanted\, only shows the low integrity and professionalism of the group involved. It's not the first time I've had whiners backstabbing and politicizing behind my back. But rarely does anyone pay them any official head as it would be stooping to their level.

My behavior is usually unrepentant for things that the other person had chose to feel offended and that I had no personal stake in offending. That is a trait many find irritating\, OTOH\, At the same time\, my behavior rarely falls into the vindictive\, vengeful\, or destructive side\, it's not worth the energy.

That's no excuse.

---

No\, it's not -- it's a context and characterization that sets a stage for future events to reinforce the label -- because that's what others have experienced. Sides\, I don't need an excuse. I wasn't the person who engaged in lynch mob activity\, nor any official person who allowed such. I didn't engage in power-over domination games like some people showed a great willingness to.

About 4-5 years ago\, or so\, on the vim-list\, perl and python were neck & neck in supporters. perl's votes for feature support for perl fell to the lowest ever -- about 20-25% of the votes supporting python integration... which is now on the proposed feature list.

Yep... those who are in charge of perl are doin' a bang up job.
I can think of 2 languages from the 60's that were popular. One became bogged down in compatibility and refused to change\, the other had new standards released and grew. Fortran *survived*....not that it's popular\, mind you\, but it survived. Cobol ... not so much.

The current maintainers have put perl on the Cobol path which urks me no end. But I can really say I tried -- even to the point of having the current owners frothing at the mouth to get rid of me.

As far as people choosing to be offended -- the story I told about the old man who refused to change his habits and how it became a real problem was one told to a public group in a drivers ed class. No one seemed to take offense at the story\, so I'm pretty sure the story isn't inherently offensive\, which is what I mean by some people can *choose* to be offended over anything.

[p5pRT]

From perl-diddler@tlinx.org

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Re​: ability to reopen or close my own bugs.

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.----

---

It just occurred to me that you don't even see that as strange.

Why would special permission NOT be needed for other larger and more heavily used projects like 'Firefox & Thunderbird (and related)\, Linux Kernel\, Samba\, SourceForge (many projects)\, Novell\, and OpenSuSE\, but it is so vitally needed on Perl. I tried to think of the answer\, and it seems\, explainable\, insomuch that it _reflects_ the tight holding of power of power in the perl community and the unwillingness and or lack of trust of their own users. How could that not reflect on the community as a whole?

[p5pRT]

From @ikegami

On Mon\, May 27\, 2013 at 4​:11 PM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

Rather than just demonstrating your rudeness\, would you care to show me exactly what rude event caused the removal of my ability to reopen or close my own bugs.

No-one is granted the ability to close their own bugs.

[p5pRT]

From @nwc10

On Mon\, May 27\, 2013 at 08​:06​:38PM -0700\, Linda Walsh via RT wrote​:

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Re​: ability to reopen or close my own bugs.

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.---- --- It just occurred to me that you don't even see that as strange.

Why would special permission NOT be needed for other larger and more heavily used projects like 'Firefox & Thunderbird (and related)\, Linux Kernel\, Samba\, SourceForge (many projects)\, Novell\, and OpenSuSE\, but it is so vitally needed on Perl. I tried to think of the answer\,

You seem to be in a minority of one on that opinion. You really are the *only* person who views this as a problem.

and it seems\, explainable\, insomuch that it _reflects_ the tight holding of power of power in the perl community and the unwillingness and or lack of trust of their own users. How could that not reflect on the community as a whole?

No. Specifically\, on the particularly old version of the ticketing system I believe that it is not possible to permit non-admin accounts to close their own tickets without also enabling those accounts to perform several other actions which are not appropriate for non-admins.

There is work ongoing to upgrade to a newer version\, but it involves forward porting the heavy customisations we rely on\, so it hasn't been trivial. The newer version may well have the flexibility to permit end users to close their tickets (and other relevant modifications) without also enabling every admin function.

Nicholas Clark

[p5pRT]

From perl-diddler@tlinx.org

On Mon May 27 23​:29​:46 2013\, ikegami@​adaelis.com wrote​:

On Mon\, May 27\, 2013 at 4​:11 PM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

Rather than just demonstrating your rudeness\, would you care to show me exactly what rude event caused the removal of my ability to reopen or close my own bugs.

No-one is granted the ability to close their own bugs.

Then can you explain why I had it and still do on bug databases except Perl's? If I submit a problem and realize it is not a problem\, why shouldn't I be able to close it?

If the submitter doesn't think something is a bug anymore\, why shouldn't they be allowed to close it?

On Tue May 28 01​:32​:00 2013\, nicholas wrote​:

You seem to be in a minority of one on that opinion. You really are the *only* person who views this as a problem.

---

Simply the fact that I submit bug puts me in a minority. I would wager that someone who submits bugs across a wide range of separate projects tends to be a small minority of individuals.

Certainly\, given the above\, it would be an even smaller minority that would regularly engage with the bug systems on a variety of products and know what norms are like on other projects. Of those people I find it hard to believe\, but not impossible that the number of people willing to actually report or write anything about it = 1. But I find myself noticing alot of things that others don't (while missing things that other take the presence of\, as granted).

and it seems\, explainable\, insomuch that it _reflects_ the tight holding of power of power in the perl community and the unwillingness and or lack of trust of their own users. How could that not reflect on the community as a whole?

No. Specifically\, on the particularly old version of the ticketing system I believe that it is not possible to permit non-admin accounts to close their own tickets without also enabling those accounts to perform several other actions which are not appropriate for non-admins.

---

  I don't know about any specific "old version" of the ticketing system -- I can only go by what I interact with 'currently' in various projects and how much it has stayed the same or changed over the past few decades.

There is work ongoing to upgrade to a newer version\, but it involves forward porting the heavy customisations we rely on\, so it hasn't been trivial. The newer version may well have the flexibility to permit end users to close their tickets (and other relevant modifications) without also enabling every admin function.

It only came up for me as I had it on this project the same as most other projects I submit bugs on until recently.

I wouldn't think anything of the ability to close out my own bugs\, as that is the norm on 90+ percent of projects using a more advanced bug/issue tracking system. Anything that is anomolous on one project\, tends to stand out to me\, as being different\, only because I use the interfaces of so many projects.

Other oddities -- one project that requires that posts to its bug system be "approved" by a moderator before being entered into the bug-database (this is on top of a requirement that one be registered at the site before submitting bugs in the first place).

Or -- projects that use social-billboard-discussion systems that don't interact well with email (if at all).

Though\, that said\, perl is unique in singling me out to not be allowed to post updates to my bugs via email when most other users can respond to their bugs and my bugs via email. I'm sure that if other people has the same experiences I did\, you might find more people speaking up about perceived problems -- at least among those who care to any degree.

[p5pRT]

From @rjbs

* Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org [2013-05-27T19​:20​:17]

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets. ---- So until about 2-3 weeks from several years back\, I was special\, but now I'm not. You may be speaking in all honest\, but the timing is more than a little coincidental.

Your rights regarding open/close tickets are not special. They're the same as any other non-admin. The setting was changed not too long ago in response to a security audit.

It was done after the "top level administrative power" got a series of complaints about your behavior on the list\, and after you have been asked multiple times to change your behavior. --- My behavior wasn't at issue.

No. It was your behavior. After being repeatedly asked to tone down the attitude you have taken toward other members of the list\, and after your repeated failure to do so\, you were removed from the list.

It was my political views regarding perl. My behavior was no worse than anyone who attacked me\, just that I had alot of detractors. The fact that any official body would step in and give over to the children what they wanted\, only shows the low integrity and professionalism of the group involved. It's not the first time I've had whiners backstabbing and politicizing behind my back. But rarely does anyone pay them any official head as it would be stooping to their level.

This is absurd. If anything\, your removal from the list was performed to help improve the atmosphere of the list following repeated complaints.

I don't need an excuse. I wasn't the person who engaged in lynch mob activity\, nor any official person who allowed such. I didn't engage in power-over domination games like some people showed a great willingness to.

A lynch mob finds an innocent person and murders them.

What happened here was that you were found to be a repeat offender in making the list much worse place\, and you were removed from the list to go continue your life elsewhere.

I am sorry that you are unable to see from our perspective how your behavior has been unacceptable. Nonetheless\, it has been\, and it has been pointed out over and over.

Please limit your bug reporting to reporting bugs.

-- rjbs

[p5pRT]

From @ikegami

On Tue\, May 28\, 2013 at 8​:50 AM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

On Mon May 27 23​:29​:46 2013\, ikegami@​adaelis.com wrote​:

On Mon\, May 27\, 2013 at 4​:11 PM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

Rather than just demonstrating your rudeness\, would you care to show me exactly what rude event caused the removal of my ability to reopen or close my own bugs.

No-one is granted the ability to close their own bugs.

Then can you explain why I had it and still do on bug databases except Perl's?

We have no control over other bug databases. You'll have to ask them.

[p5pRT]

From @dmcbride

On Tuesday May 28 2013 9​:31​:18 AM Nicholas Clark wrote​:

On Mon\, May 27\, 2013 at 08​:06​:38PM -0700\, Linda Walsh via RT wrote​:

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Re​: ability to reopen or close my own bugs.

Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.----

--- It just occurred to me that you don't even see that as strange.

Why would special permission NOT be needed for other larger and more heavily used projects like 'Firefox & Thunderbird (and related)\, Linux Kernel\, Samba\, SourceForge (many projects)\, Novell\, and OpenSuSE\, but it is so vitally needed on Perl. I tried to think of the answer\,

You seem to be in a minority of one on that opinion. You really are the *only* person who views this as a problem.

If you're saying that she's a minority of one on the opinion that bug reporters should have the ability to reopen / close their own reported bugs\, I don't think that to be the case\, as I count two already. (Yeah\, me.) I would\, however\, be in favour of open-source issue trackers being able to lock bug states based on bug identifier and/or reporter identifier (i.e.\, being able to lose the privilege of being able to reopen bug reports based on a history of abuse).

However\, if you're saying that she's a minority of one on how to respond to that\, well\, then\, I expect you're right :) Personally\, I simply add remarks to bugs I think were prematurely closed (or are still open when they don't need to be)\, and let someone else handle it. In those\, admittedly rare\, cases\, I just haven't found any issue.

Note that I do this even on bug trackers where I *do* have the ability to reopen my own defects. The only exception is at $work\, where I re-open defects with righteous anger even if neither the owner nor the reporter are on my team :) So\, while I understand Linda's frustration\, I don't understand her response.

and it seems\, explainable\, insomuch that it _reflects_ the tight holding of power of power in the perl community and the unwillingness and or lack of trust of their own users. How could that not reflect on the community as a whole?

No. Specifically\, on the particularly old version of the ticketing system I believe that it is not possible to permit non-admin accounts to close their own tickets without also enabling those accounts to perform several other actions which are not appropriate for non-admins.

This is a particularly reasonable\, albeit unfortunate\, response.

[p5pRT]

From perl-diddler@tlinx.org

On Wed May 29 19​:41​:26 2013\, dmcbride@​cpan.org wrote​:

On Tuesday May 28 2013 9​:31​:18 AM Nicholas Clark wrote​:

On Mon May 27 15​:38​:46 2013\, LeonT wrote​:

Re​: ability to reopen or close my own bugs. Only people with special permissions to do so can do that. Which is mostly (/only?) core committers. There's nothing personal about that\, most people on p5p can't close/reopen tickets.

It just occurred to me that you don't even see that as strange.

Why would special permission NOT be needed for other larger and more heavily used projects like 'Firefox & Thunderbird (and related)\, Linux Kernel\, Samba\, SourceForge (many projects)\, Novell\, and OpenSuSE\, but it is so vitally needed on Perl. I tried to think of the answer\,

You seem to be in a minority of one on that opinion. You really are the *only* person who views this as a problem.

If you're saying that she's a minority of one on the opinion that bug reporters should have the ability to reopen / close their own reported bugs\, I don't think that to be the case\, as I count two already. (Yeah\, me.) I would\, however\, be in favour of open-source issue trackers being able to lock bug states based on bug identifier and/or reporter identifier (i.e.\, being able to lose the privilege of being able to reopen bug reports based on a history of abuse).

---

  Absolutely.... thats *normal*\, which is why I was feeling a bit snubbed by the removal of "priviledges" that I see as normal most places\, when I didn't see any reason why I should have lost those privileges other than someone thinking that for the first time in several years that I've had an account it was a good idea to do a security audit that just happened to included criteria that would disable my access\, when someone (Leon?) and complained and asked why I hadn't just recategorized a bug over opening an old bug\, but getting no response had to open a new one. Seemed like my ability to reopen or close my own bugs went dead right after that incident. Given the timing of the ''security audit''\, you'll have to try to see that from my point of view\, it seemed personally directed when I didn't feel I had engaged in any activity abusing the system.

  I'm sorry\, but the timing of the incident leaves it looking more like it had personal motivations behind it rather than it being a routine security audit. Given the fairness with which people in this community have dealt with me\, how could a reasonable person NOT have suspicion about motives?

However\, if you're saying that she's a minority of one on how to respond to that\, well\, then\, I expect you're right :)

---

  I certainly thought the treatment of me was rather unique.

Personally\, I simply add remarks to bugs I think were prematurely closed (or are still open when they don't need to be)\, and let someone else handle it. In those\, admittedly rare\, cases\, I just haven't found any issue.

---

  Forgive me for being a bit sensitive\, but I've had people close out my bugs in less than 30 minutes -- claiming it was not a bug\, but clearly not even bothering to understand what was being said as others pointed out that it was a bug.

  It reminds me a bit of slashdot and those posters who try to get first post.

  That it has happened more than once only helps remind me of the respect these people want me to give to them.

  That's always been the problem. I respond to people as they treat me -- and they wonder why they don't like my attitude?

and it seems\, explainable\, insomuch that it _reflects_ the tight holding of power of power in the perl community and the unwillingness and or lack of trust of their own users. How could that not reflect on the community as a whole?

No. Specifically\, on the particularly old version of the ticketing system I believe that it is not possible to permit non-admin accounts to close their own tickets without also enabling those accounts to perform several other actions which are not appropriate for non-admins.

This is a particularly reasonable\, albeit unfortunate\, response.

---

  It would be even more reasonable if the timing hadn't been so coincidental. Indeed\, in light of finding possible security problems\, it would have been even wiser to have observed the responsiblity of those who knowingly had such access for years and would no more consider abusing it than at any of the other dozen or more sites where open access is the norm. One would wonder why\, with the facility in perl that a group who maintains perl.org would have\, or with the easy availability of products that don't have these limitations there hasn't been any move to move to a system that meets their security needs without causing some to sonder about motives.

  Someone being paranoid doesn't reflect on the potential that their paranoia is based on accumulated evidence. But it could all be coincidental. Hmmm.