

Fix Radar or GTFO - pooriaazimi
http://www.marco.org/2012/05/08/fix-radar-or-gtfo

======
veidr
I once had an interesting experience when visiting Apple. I was telling a DTS
engineer about a gnarly bug in the Cocoa text system I had found (certain text
editing sequences would silently corrupt the undo stack; user might not notice
until they accidentally did a select-all and delete, and then tried to undo to
get their novel back).

I never got any feedback on this bug at all (just like always).

But, this Apple guy looked up the bug on their internal radar tool (a native
Mac app, not some crappy web interface). There were screens full of
discussion, with engineer's names I recognized, and the bug has been elevated
to "Show-Stopper" status, which he told me meant the next release wouldn't
ship without a fix.

What I took from this is that Apple's internal tools for bug triage,
discussion, and prioritization are relatively sophisticated and heavily used,
but they have nothing to do with the pathetic, rude, uninformative Radar
interface that we peons who pay Apple for the privilege of developing for
their platform get to see. It was kind of interesting to get a peek inside
from their perspective.

Having said that, though, I almost never file Radar issues anymore, for
exactly the same reason that I don't go to Apple's offices and clean their
toilets for free.

~~~
brendn
I find the toilet analogy to be flawed. Sure you don't fix their toilets for
free, but you would certainly let someone know if you used one of their
facilities and found it to be clogged or otherwise malfunctioning.

As a someone who's filed a few Radar issues over the years, I understand that
the lack of feedback is frustrating, but I find it absurd that the way to fix
that is to withhold the bug reports that help improve the software we use and
develop for daily.

~~~
veidr
Well no, to be honest, I certainly don't do that. If I am at say, Moscone
Center or a Wal-mart or a low-rent casino, and a toilet is clogged with shit,
I don't go wandering around to hunt down a maintenance man and report it to
him. I just use another stall.

Now, if it was instead the toilet at a restaurant or other venue that I
frequent, where I am welcomed and treated with respect, then of course I would
alert the staff to their problem.

But a developer's relationship with Apple is much more the former than the
latter. (I file really awesome bug reports for other software I use, like
OmniGraffle or Arq.)

It's also important to note that I didn't _begin_ with this attitude; I _ended
up with it_ after filing dozens of detailed Radar bugs over the years, and
evaluating how shitty the response from Apple is.

As others have pointed out, if a developer spends 5+ hours isolating a
crippling bug in your shit[1], and filing it with a repro case[2], and you
don't even have the courtesy to let them follow changes to the bug when it's
marked as a duplicate, then well... you're kind of a rude and arrogant
asshole. So developers become less likely to keep performing this service for
you... unless they _really_ _really_ _really_ want the bug fixed.

[1]<http://masonmark.com/the-xcode-fairy>

[2]<https://github.com/masonmark/XcodeCorruptOnOpenBugDemo>

------
fredley
We (my company) have filed quite a few radar bug reports, including one quite
serious flaw (account passwords being sent across a network in plaintext
serious). We never heard a squeak back. We never know if they have, or will
ever be fixed in a future release.

Some of these bugs affect our software critically, but we're completely in the
dark about whether we should invest serious time and energy into providing our
own workaround or leave it as it'll be fixed in the next Mountain Lion
Preview.

This lack of communication is one of the worst things about being an Apple
developer, and I fully support the community's efforts to try and persuade
them to do better.

------
acdha
I've filed many bugs with Apple over the years. There are two strategies which
work:

1\. For security issues, use full disclosure. I received phone calls
immediately when I included something like "disclosure in 30 days unless
otherwise requested". Otherwise bugs were fixed in the next OS release a year
later.

2\. Otherwise: our Apple rep (.edu) told us that bugs were prioritized based
on how many Macs you couldn't buy until it was fixed. Later, this changed to
how the bug was preventing you from deploying iPhones (“iPhone: it's like sudo
for Apple”) and I imagine this now includes iPads.

~~~
tptacek
"Disclosure in 30 days unless otherwise requested".

I love this so much. "Unless otherwise requested". Perfect.

------
damncabbage
"Fix Radar or... Carry on making large sums of money regardless."

Developers aren't their primary concern. Look at Xcode for crying out loud
(and wonder at its magical ever-crashing nature).

~~~
Bxstraz
XCode has never crashed for me in 3+ years.

Your project is corrupt. You're doing something wrong. Look to a professional
for assistance with your IDE.

~~~
delinka
You're not using Xcode. I mean Really Using Xcode. Like making a serious
attempt at exercising its features. Hell, you really don't even have to do
that. Create a project, edit some code, compile and run your app. That's
usually fine. Now, try repeatedly, several times a minute for eight hours
straight to use the debugger on your app (intentionally overrelease something
or create some other reason for Xcode to launch lldb when your app crashes.)

Xcode will crash.

------
Gring
This has been solved already: <http://openradar.appspot.com>

If you file a new bug with Apple, publish it here as well. No more black hole,
you can see what others have already posted. You can even see what duplicates
are about (if the original bug was also at open radar).

~~~
moron
Interesting usage of the word "solved", there.

~~~
Gring
Yeah, well let's say "partially solved".

------
casca
Why would Apple want to "fix" Radar? It seems to meet _their_ requirements
quite well:

\- Developers have a place that they can report things which is industry best
practice

\- They don't need to put in as much money to staffing it

If it's a big enough issue then they'll hear about it through other channels.

(EDIT: formatting)

~~~
fredley
This is exactly why action on the part of developers is a good idea. Obviously
Apple doesn't need to fix it, the current system is serving them well enough.
Apple's target market are its users not its developers, and that's fine.

However, as a developer, I'm going to be trying my hardest to pressure Apple
into making my life easier, and the more people doing the same the better.
Just because they can get away with this sort of thing, and it makes logical
sense for them to do so doesn't mean that's the way things have to stay. A
better ecosystem for Apple developers is a better ecosystem for their end-
users, down the line, anyway.

------
npsimons
Did anyone else click on the link hoping for a nice juicy technical article
about RADAR (<http://en.wikipedia.org/wiki/Radar>) and not some whining about
a piece of software that would have been fixed by now if it was open source?

------
nicholassmith
I don't this is specifically an Apple issue either, I've filled bug reports on
quite a few different projects (mostly open source) including at least one
that's a full application framework and rarely do they ever move into
'confirmed' or 'accepted' status.

The entire reason of letting people add bugs is that they can be tracked, if
the submitter can't track it then why would they want to add it? If you can't
see a perceived benefit then you're going to lose interest in reporting the
bugs which in the long term is bad for the overall package.

~~~
viraptor
I believe that at a certain size of the project you will get more incoming
bugs than you can handle. Doesn't matter if it's closed/open source, who the
users are or anything else. It's just a matter of the number of users / size
of QA.

Basically over some threshold you'll get conflicting behaviour expectations,
duplicates formulated differently so they cannot be linked, QA finding more
tiny issues in every release than bugfixes going in, etc. At least that's what
I've seen so far from both open and closed projects.

(wxWidgets still takes the cake, asking me if the bug still exists after ~8
years since initial report)

~~~
nicholassmith
True, it's definitely a case where eventually the number of bugs becomes
incredibly difficult to manage but it's still essentially training people to
not report bugs if they can't see even the smallest amount of traction on it.

------
n9com
If you file a bug report on Radar, unless you know someone at Apple who you
can give the Report ID to, it is unlikely to be dealt with quickly. Seems like
they don't have a dedicated team overlooking it.

~~~
acdha
This is definitely false: they respond quickly with initial triage. The main
problem is that you will subsequently almost never hear anything from them and
if your issue was reported as a duplicate you'll need to manually poll them
over email for the status.

------
makecheck
There's already an effort to do this:

<http://fixradarorgtfo.com/>

500+ developers so far have submitted this to Apple.

~~~
smackfu
If you didn't notice, this blog post is inspired by that site and links to it.

------
mfringel
I'm not sure what the problem is. Apple has created a filter to bug reporting
that they're clearly comfortable with.

~~~
smackfu
The problem is that you can't get real tracking on your business critical bugs
because Apple just marks them as duplicates. And once it's a duplicate, you
can't see the status, so you never know if it's actually fixed. So why even
bother reporting bugs?

Here are my stats from Radar:

4 Open - All over two years old.

7 Duplicate

1 Closed - The only one I got a response back on, and that Apple said was
fixed.

