6 ms·

I love these kind of bug-hunting stories. The Apple engineer that fixed the bug (and remains nameless), provided an explanation, which happily surprised me. I u

by bartvk 4y ago

I love these kind of bug-hunting stories. The Apple engineer that fixed the bug (and remains nameless), provided an explanation, which happily surprised me. I usually read wry remarks on Twitter about the black hole that's called Radar.

130e13a 4y ago
> and remains nameless WebKit is open-source, so it is actually one of the few Apple projects where the developers do not not remain nameless (the other big one being Swift). > the black hole that's called Radar IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view)
- lapcat 4y ago
  > IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view) The funny thing though is that Apple still sends WebKit bugs into Radar to work on them: https://bugs.webkit.org/show_bug.cgi?id=232939#c6 https://bugs.webkit.org/show_bug.cgi?id=232939#c6
  - marcellus23 4y ago
    That isn’t surprising. Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team.
    - lapcat 4y ago
      > Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team. bugs.webkit.org is literally a bug tracker. The only relevant difference between Radar and WebKit Bugzilla is private vs. public.
      - olliej 4y ago
        No. B.w.o has no release tracking, it has no ability to track dependencies on other Apple projects, etc B.w.o is where bug fixes happen, no more. Code dev and review has to happen in b.w.o by the webkit community rules, not radar.
        saagarjha 4y ago
        That’s now on GitHub.
      - dagmx 4y ago
        There’s also a difference between WebKit (the open source code) and Safari (the closed source software) I assume internally they’re treated as one component which makes it easier to mirror bugs into radar?
        saagarjha 4y ago
        WebKit has a closed source component that ships alongside Safari, which is entirely closed source.
      - marcellus23 4y ago
        > The only relevant difference between Radar and WebKit Bugzilla is private vs. public. No, this is not true. Radar is not just "a bug tracker" — it is a very powerful project management tool, custom-built over several decades for the way Apple works, with integrations into other internal tools and processes. It should be obvious why Apple wants to track work being done on Webkit using the same tool it uses to track work being done on every other project at the company.
        lapcat 4y ago
        Last time I saw Radar, and its source code, which was admittedly over a decade ago, it was not a "project management tool" as such, although radars could of course be used in project management. It was indeed just a bug tracker, but yes, a very powerful one. At bottom it was a giant Oracle database, with several frontends.
  - olliej 4y ago
    Webkit bugs do not get transferred to radar to be worked on. Assuming the bug is actually in webkit (eg not a bug in the safari app or an underlying system framework), all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. There are many reasons for linking bugzilla bugs to radar, but the big ones are scheduling, other project dependencies inside Apple, security reports (so that reporters can be mentioned in release notes, etc). The important thing is that the b.w.o->radar cross referencing is not for development specifically.
    - lapcat 4y ago
      > all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. What about discussion? Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla.
      - madeofpalk 4y ago
        > Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? Open source bugs will have private/non-public conversations (whether it's in person, or on slack, or on a seperate issue tracker) all the time. That's not abnormal or all that damning.
        deleted 4y ago
        [deleted]
      - olliej 4y ago
        > What about discussion? Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back? > Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? No, I'm saying your claim that "The funny thing though is that Apple still sends WebKit bugs into Radar to work on them:" is nonsense. The reason that bugs are cloned to radar is so that they can be tracked for releases. I think you have decided that any time you don't see discussion in b.w.o it means discussion there must be discussion in radar, and that's false. The reality is that most bug fix/feature implementation doesn't require discussion during development, actual recorded discussion happens during review as that systematically results in recording the exchanges. > I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug. > You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla. For many there's not anything in radar either, because many (most?) bugs you see are created to track reviewing the change, and don't exist before the review process. The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.
dagmx 4y ago
As someone who’s worked in a role supporting a high ratio of people to developers in animation production, I often wonder how much of the radar black holeness is just a ratio issue. Afaik Apple runs really small teams versus other companies. I know when I once interviewed around FAANG, the Apple teams were significantly smaller (like 5x smaller in some cases…probably also why they aren’t part of this mass tech layoffs). I used to find in my old film job that no matter how much I churned through tickets , there was just no getting out from the stigma of being unresponsive because the person on the other end of the ticket can’t see what your workload and priorities are like. That’s not to say Apple isn’t at fault for having small teams, but I think a lot of people assume the engineers themselves don’t care to fix stuff. Though at least in my case, I could tell my users that I was working on stuff and to expect it at some time in the future. I assume Apple’s engineers are even more hamstrung by their extreme secrecy. I know the few feedback radars I’ve gotten responses from were basically “can reproduce” to “fixed in the latest OS release” without any feedback in between. anyway all that is to say, I often see people blame the engineers (you didn’t but I see others do) whereas I think it’s a corporate culture issue that engineers are beholden to.
- lapcat 4y ago
  > I know the few feedback radars I’ve gotten responses from were basically “can reproduce” Wait, you get "can reproduce" responses??? I never get that, I think literally never in over 15 years, but it would be a vast improvement to my bug reporting experience.
  - dagmx 4y ago
    I should say it’s usually 1. Submit bug 2. Get a cannot reproduce , please provide more information 3. Submit more info as requested 4. “Okay we can reproduce. Thanks” 5. Nothing for ages 6. Okay it’s fixed Step number 5 almost always aligns with their OS release (point and major) schedules in my experience. macOS 13.1 just came out so if I filed a minor bug now, I’d probably not hear anything till June (WWDC) or if I’m lucky, in one of the point releases that happens every couple months.
    - 4y ago
kccqzy 4y ago
Why did you call them nameless? Their name is readily available, Myles C. Maxfield.

by bartvk 4y ago

130e13a 4y ago

> and remains nameless WebKit is open-source, so it is actually one of the few Apple projects where the developers do not not remain nameless (the other big one being Swift). > the black hole that's called Radar IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view)

lapcat 4y ago
> IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view) The funny thing though is that Apple still sends WebKit bugs into Radar to work on them: https://bugs.webkit.org/show_bug.cgi?id=232939#c6 https://bugs.webkit.org/show_bug.cgi?id=232939#c6
- marcellus23 4y ago
  That isn’t surprising. Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team.
  - lapcat 4y ago
    > Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team. bugs.webkit.org is literally a bug tracker. The only relevant difference between Radar and WebKit Bugzilla is private vs. public.
    - olliej 4y ago
      No. B.w.o has no release tracking, it has no ability to track dependencies on other Apple projects, etc B.w.o is where bug fixes happen, no more. Code dev and review has to happen in b.w.o by the webkit community rules, not radar.
      - saagarjha 4y ago
        That’s now on GitHub.
    - dagmx 4y ago
      There’s also a difference between WebKit (the open source code) and Safari (the closed source software) I assume internally they’re treated as one component which makes it easier to mirror bugs into radar?
      - saagarjha 4y ago
        WebKit has a closed source component that ships alongside Safari, which is entirely closed source.
    - marcellus23 4y ago
      > The only relevant difference between Radar and WebKit Bugzilla is private vs. public. No, this is not true. Radar is not just "a bug tracker" — it is a very powerful project management tool, custom-built over several decades for the way Apple works, with integrations into other internal tools and processes. It should be obvious why Apple wants to track work being done on Webkit using the same tool it uses to track work being done on every other project at the company.
      - lapcat 4y ago
        Last time I saw Radar, and its source code, which was admittedly over a decade ago, it was not a "project management tool" as such, although radars could of course be used in project management. It was indeed just a bug tracker, but yes, a very powerful one. At bottom it was a giant Oracle database, with several frontends.
- olliej 4y ago
  Webkit bugs do not get transferred to radar to be worked on. Assuming the bug is actually in webkit (eg not a bug in the safari app or an underlying system framework), all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. There are many reasons for linking bugzilla bugs to radar, but the big ones are scheduling, other project dependencies inside Apple, security reports (so that reporters can be mentioned in release notes, etc). The important thing is that the b.w.o->radar cross referencing is not for development specifically.
  - lapcat 4y ago
    > all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. What about discussion? Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla.
    - madeofpalk 4y ago
      > Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? Open source bugs will have private/non-public conversations (whether it's in person, or on slack, or on a seperate issue tracker) all the time. That's not abnormal or all that damning.
      - deleted 4y ago
        [deleted]
    - olliej 4y ago
      > What about discussion? Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back? > Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"? No, I'm saying your claim that "The funny thing though is that Apple still sends WebKit bugs into Radar to work on them:" is nonsense. The reason that bugs are cloned to radar is so that they can be tracked for releases. I think you have decided that any time you don't see discussion in b.w.o it means discussion there must be discussion in radar, and that's false. The reality is that most bug fix/feature implementation doesn't require discussion during development, actual recorded discussion happens during review as that systematically results in recording the exchanges. > I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug. > You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla. For many there's not anything in radar either, because many (most?) bugs you see are created to track reviewing the change, and don't exist before the review process. The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.

dagmx 4y ago

As someone who’s worked in a role supporting a high ratio of people to developers in animation production, I often wonder how much of the radar black holeness is just a ratio issue. Afaik Apple runs really small teams versus other companies. I know when I once interviewed around FAANG, the Apple teams were significantly smaller (like 5x smaller in some cases…probably also why they aren’t part of this mass tech layoffs). I used to find in my old film job that no matter how much I churned through tickets , there was just no getting out from the stigma of being unresponsive because the person on the other end of the ticket can’t see what your workload and priorities are like. That’s not to say Apple isn’t at fault for having small teams, but I think a lot of people assume the engineers themselves don’t care to fix stuff. Though at least in my case, I could tell my users that I was working on stuff and to expect it at some time in the future. I assume Apple’s engineers are even more hamstrung by their extreme secrecy. I know the few feedback radars I’ve gotten responses from were basically “can reproduce” to “fixed in the latest OS release” without any feedback in between. anyway all that is to say, I often see people blame the engineers (you didn’t but I see others do) whereas I think it’s a corporate culture issue that engineers are beholden to.

lapcat 4y ago
> I know the few feedback radars I’ve gotten responses from were basically “can reproduce” Wait, you get "can reproduce" responses??? I never get that, I think literally never in over 15 years, but it would be a vast improvement to my bug reporting experience.
- dagmx 4y ago
  I should say it’s usually 1. Submit bug 2. Get a cannot reproduce , please provide more information 3. Submit more info as requested 4. “Okay we can reproduce. Thanks” 5. Nothing for ages 6. Okay it’s fixed Step number 5 almost always aligns with their OS release (point and major) schedules in my experience. macOS 13.1 just came out so if I filed a minor bug now, I’d probably not hear anything till June (WWDC) or if I’m lucky, in one of the point releases that happens every couple months.
  - 4y ago

kccqzy 4y ago

Why did you call them nameless? Their name is readily available, Myles C. Maxfield.