7 ms·

Scary. Even more scary is the fact that the bug has been open for a week, one person has confirmed 100% reproducibility, and no one seems to care at Red Hat. Is

Scary. Even more scary is the fact that the bug has been open for a week, one person has confirmed 100% reproducibility, and no one seems to care at Red Hat. Isn't deleting peoples hard drives a big no no ?

rwmj 12y ago
It's already fixed, plus there are many private comments which you cannot see (but I think you see "missing" comment numbers). Also the product in question is not released yet. It's good this was found, but no customer would have been affected unless they were using an alpha.
- deleted 12y ago
  [deleted]
cynix 12y ago
RedHat is pleased to announce the general availability of our new RedHat Enterprise Data Recovery service. Please contact your account manager for details.
TheDong 12y ago
It already has a "fixed in version" listed. Fixing it within a day doesn't sound like no one caring :) Does it really matter if no one commented "Oops, we screwed up"? It's kinda self-evident that there was a mistake and there's not really much to say; it's clear from the description how bad it is and marking it "Fixed in version" already says it all pretty much.
- EdwardDiego 12y ago
  > Does it really matter if no one commented "Oops, we screwed up"? To me it does. You just deleted someone's hard drive, an apology wouldn't be out of order.
  - TheDong 12y ago
    When you're a QA engineer at RHEL working on an UNRELEASED PRODUCT then no, I don't think you need an apology. Maybe a thanks for finding the bug, but this is the whole point of QA and the whole point of QA-ing before it's released. The context matters a lot. This title is linkbait. It omits mentioning that this was not publicly released and the reporter is a QA for Red Hat. Given that context I doubt you'll still agree an apology is so necessary or that this was not handled well.
    - vacri 12y ago
      This being said, the bugtracker isn't very clear when it comes to ticket status. Currently the status is 'on_qa'. I guess if you use it a lot you're aware of it, but it strikes me as iffy UI.
      - blcknight 12y ago
        It's exceptionally clear for anyone even remotely familiar with RHEL or Bugzilla. It's not mean for any joe's consumption anyway, this is a work tool used by developers and QE...
        vacri 12y ago
        'exceptionally clear'? How do you detect that bug status from across the room? If that bug page was up on a big screen, how do you detect it's status? How do you tell at a glance from a meter away what the status is? All of those things should be doable for an 'exceptionally clear' status. Developers don't have mysteriously different visual capabilities from 'joes'. this is a work tool used by developers and QE Because as we all know, developers don't benefit from good UIs. One wonders why they would use a webpage at all, rather than simply connect to an ncurses-based bugtracker that only supports an 80x24 terminal.
        res0nat0r 12y ago
        > How do you detect that bug status from across the room? Know and understand the tools you are working with, and simply click the Modified (History) link at the top to determine the bug timeline: https://bugzilla.redhat.com/show_activity.cgi?id=1202858 https://bugzilla.redhat.com/show_activity.cgi?id=1202858
raldi 12y ago
And this is why every bug tracking system should have a triage SLA. Or, even if you don't want to declare a threshold, publish the current stats on its front page: "Over the last 30 days, our 99-percentile triage wait time was: XX hours." Similarly, open tickets with priority=urgent should never go 24 hours without a new comment from the owner.
- Animats 12y ago
  "Or, even if you don't want to declare a threshold, publish the current stats on its front page: "Over the last 30 days, our 99-percentile triage wait time was: XX hours." Now there's a good idea. Major open source projects should have software quality dashboards tracking things like that. We're now seeing hospital emergency rooms displaying their current wait time in minutes on billboards.
deleted 12y ago
[deleted]
oogway 12y ago
Well, the bug was reported against RHEL 6.7 which has not been released yet.
- cssmoo 12y ago
  RH don't have a great reputation here. Unlike Debian which does proper triage and practices "zero release-critical bugs", RH threw out RHEL7 with loads of critical issues still open.
  - rwmj 12y ago
    This is simply not true. Could you provide evidence rather than making stuff up.
    - cssmoo 12y ago
      Ok. Fresh steaming proof as requested: https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&bug_severity=high&bug_status=NEW&bug_status=ASSIGNED&order=Importance&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced&version=7.1 https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&... All high severity bugs against 7.1 which was relased 16 days ago. Check the dates on half of them. They're before the release date and half of them haven't even been assigned or triaged. When 7.0 came out, datetimectl and systemd didn't even work properly. Enabling ntp threw dbus errors galore. On some kit it didn't even boot. Total lemon. RHEL doesn't generally work properly until the .2 releases. I've been using it for 10 years so I've got plenty of experience on the matter. I would go into detail about the CIFS/smb kernel hangs I've had on 6.x but I've had enough of it by now.
      - vidarh 12y ago
        Redhat Linux (not RHEL) tended to have issues until the ".2" releases too, all the way back to 4.x in '96/'97.
      - rwmj 12y ago
        The priority fields are set by developers so they know which bugs they should work on first. The two bugs of mine which appear on that list are both new features for RHEL 7.2. I set the priority of those so I know to work on them first. I really think you need a better query than that one. Update: I think if you wanted to find out which critical bugs affected RHEL 7.0 on release, you'd probably want to look at the list of z-stream packages (RHEL 7.0.z) which subscribers have access to. These are bugs which didn't affect the installer or first boot, but were important enough to need fixing in RHEL 7.0 after it went out. (If a bug was critical enough to affect installation or first boot, it would have delayed the release).
cellularmitosis 12y ago
Ahh Redhat, the distro which chose to symlink a bunch of binary lib files from Apache into the etc directory. "Why is grepping /etc taking so long? Binary files in /etc?!? WTF?!?" Coming from Debian, Redhat seems to make a lot of irk-worthy choices.
- Padding 12y ago
  Is there an aricle with specifics on this and why it was done?
  - teddyh 12y ago
    I have no direct information about this specific case, but in ye olden Unix™ days, there was no /sbin, so all those binaries instead lived in /etc. The Red Hat symlinks could be a backwards-compatibility thing.
    - SSLy 12y ago
      You mean bug-compability?
      - teddyh 12y ago
        No, I would not mean that, since the previous behavior was not a bug.
- Erwin 12y ago
  I find the /etc/httpd/logs symlink more annoying. If you want to grep through your Apache configuration you have to explicitly grep through conf and conf.d otherwise just going to /etc/httpd and doing a grep -r you're searching through gigs of Apache logs.
  - Tiksi 12y ago
    grep -r shouldn't follow symlinks, -R does however: -d, --directories=ACTION how to handle directories; ACTION is 'read', 'recurse', or 'skip' -D, --devices=ACTION how to handle devices, FIFOs and sockets; ACTION is 'read' or 'skip' -r, --recursive like --directories=recurse -R, --dereference-recursive likewise, but follow all symlinks

rwmj 12y ago

It's already fixed, plus there are many private comments which you cannot see (but I think you see "missing" comment numbers). Also the product in question is not released yet. It's good this was found, but no customer would have been affected unless they were using an alpha.

deleted 12y ago
[deleted]

cynix 12y ago

RedHat is pleased to announce the general availability of our new RedHat Enterprise Data Recovery service. Please contact your account manager for details.

TheDong 12y ago

It already has a "fixed in version" listed. Fixing it within a day doesn't sound like no one caring :) Does it really matter if no one commented "Oops, we screwed up"? It's kinda self-evident that there was a mistake and there's not really much to say; it's clear from the description how bad it is and marking it "Fixed in version" already says it all pretty much.

EdwardDiego 12y ago
> Does it really matter if no one commented "Oops, we screwed up"? To me it does. You just deleted someone's hard drive, an apology wouldn't be out of order.
- TheDong 12y ago
  When you're a QA engineer at RHEL working on an UNRELEASED PRODUCT then no, I don't think you need an apology. Maybe a thanks for finding the bug, but this is the whole point of QA and the whole point of QA-ing before it's released. The context matters a lot. This title is linkbait. It omits mentioning that this was not publicly released and the reporter is a QA for Red Hat. Given that context I doubt you'll still agree an apology is so necessary or that this was not handled well.
  - vacri 12y ago
    This being said, the bugtracker isn't very clear when it comes to ticket status. Currently the status is 'on_qa'. I guess if you use it a lot you're aware of it, but it strikes me as iffy UI.
    - blcknight 12y ago
      It's exceptionally clear for anyone even remotely familiar with RHEL or Bugzilla. It's not mean for any joe's consumption anyway, this is a work tool used by developers and QE...
      - vacri 12y ago
        'exceptionally clear'? How do you detect that bug status from across the room? If that bug page was up on a big screen, how do you detect it's status? How do you tell at a glance from a meter away what the status is? All of those things should be doable for an 'exceptionally clear' status. Developers don't have mysteriously different visual capabilities from 'joes'. this is a work tool used by developers and QE Because as we all know, developers don't benefit from good UIs. One wonders why they would use a webpage at all, rather than simply connect to an ncurses-based bugtracker that only supports an 80x24 terminal.
        res0nat0r 12y ago
        > How do you detect that bug status from across the room? Know and understand the tools you are working with, and simply click the Modified (History) link at the top to determine the bug timeline: https://bugzilla.redhat.com/show_activity.cgi?id=1202858 https://bugzilla.redhat.com/show_activity.cgi?id=1202858

raldi 12y ago

And this is why every bug tracking system should have a triage SLA. Or, even if you don't want to declare a threshold, publish the current stats on its front page: "Over the last 30 days, our 99-percentile triage wait time was: XX hours." Similarly, open tickets with priority=urgent should never go 24 hours without a new comment from the owner.

Animats 12y ago
"Or, even if you don't want to declare a threshold, publish the current stats on its front page: "Over the last 30 days, our 99-percentile triage wait time was: XX hours." Now there's a good idea. Major open source projects should have software quality dashboards tracking things like that. We're now seeing hospital emergency rooms displaying their current wait time in minutes on billboards.

deleted 12y ago

[deleted]

oogway 12y ago

Well, the bug was reported against RHEL 6.7 which has not been released yet.

cssmoo 12y ago
RH don't have a great reputation here. Unlike Debian which does proper triage and practices "zero release-critical bugs", RH threw out RHEL7 with loads of critical issues still open.
- rwmj 12y ago
  This is simply not true. Could you provide evidence rather than making stuff up.
  - cssmoo 12y ago
    Ok. Fresh steaming proof as requested: https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&bug_severity=high&bug_status=NEW&bug_status=ASSIGNED&order=Importance&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced&version=7.1 https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&... All high severity bugs against 7.1 which was relased 16 days ago. Check the dates on half of them. They're before the release date and half of them haven't even been assigned or triaged. When 7.0 came out, datetimectl and systemd didn't even work properly. Enabling ntp threw dbus errors galore. On some kit it didn't even boot. Total lemon. RHEL doesn't generally work properly until the .2 releases. I've been using it for 10 years so I've got plenty of experience on the matter. I would go into detail about the CIFS/smb kernel hangs I've had on 6.x but I've had enough of it by now.
    - vidarh 12y ago
      Redhat Linux (not RHEL) tended to have issues until the ".2" releases too, all the way back to 4.x in '96/'97.
    - rwmj 12y ago
      The priority fields are set by developers so they know which bugs they should work on first. The two bugs of mine which appear on that list are both new features for RHEL 7.2. I set the priority of those so I know to work on them first. I really think you need a better query than that one. Update: I think if you wanted to find out which critical bugs affected RHEL 7.0 on release, you'd probably want to look at the list of z-stream packages (RHEL 7.0.z) which subscribers have access to. These are bugs which didn't affect the installer or first boot, but were important enough to need fixing in RHEL 7.0 after it went out. (If a bug was critical enough to affect installation or first boot, it would have delayed the release).

cellularmitosis 12y ago

Ahh Redhat, the distro which chose to symlink a bunch of binary lib files from Apache into the etc directory. "Why is grepping /etc taking so long? Binary files in /etc?!? WTF?!?" Coming from Debian, Redhat seems to make a lot of irk-worthy choices.

Padding 12y ago
Is there an aricle with specifics on this and why it was done?
- teddyh 12y ago
  I have no direct information about this specific case, but in ye olden Unix™ days, there was no /sbin, so all those binaries instead lived in /etc. The Red Hat symlinks could be a backwards-compatibility thing.
  - SSLy 12y ago
    You mean bug-compability?
    - teddyh 12y ago
      No, I would not mean that, since the previous behavior was not a bug.
Erwin 12y ago
I find the /etc/httpd/logs symlink more annoying. If you want to grep through your Apache configuration you have to explicitly grep through conf and conf.d otherwise just going to /etc/httpd and doing a grep -r you're searching through gigs of Apache logs.
- Tiksi 12y ago
  grep -r shouldn't follow symlinks, -R does however: -d, --directories=ACTION how to handle directories; ACTION is 'read', 'recurse', or 'skip' -D, --devices=ACTION how to handle devices, FIFOs and sockets; ACTION is 'read' or 'skip' -r, --recursive like --directories=recurse -R, --dereference-recursive likewise, but follow all symlinks