5 ms·

> 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 on

> 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.
        marcellus23 4y ago
        I can't speak as to what Radar looked like a decade ago.
      - mproud 4y ago
        I know a story of a person who submitted a Radar ticket for an engineer to go get a haircut. They closed the ticket a few days later with a picture showing the issue resolved.
        saagarjha 4y ago
        Snakes on a Radar is always a fun list to peruse.
- 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.

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.
      - marcellus23 4y ago
        I can't speak as to what Radar looked like a decade ago.
    - mproud 4y ago
      I know a story of a person who submitted a Radar ticket for an engineer to go get a haircut. They closed the ticket a few days later with a picture showing the issue resolved.
      - saagarjha 4y ago
        Snakes on a Radar is always a fun list to peruse.
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.