[lapcat]

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

[marcellus23]

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

[mproud]

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]

Snakes on a Radar is always a fun list to peruse.

[lapcat]

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]

I can't speak as to what Radar looked like a decade ago.

[olliej]

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]

That’s now on GitHub.

[dagmx]

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]

WebKit has a closed source component that ships alongside Safari, which is entirely closed source.