On Mar 24, 2008, at 10:05 AM, Michael Marmarou wrote:
It looks like they've been sitting on this since 2003. I wonder if we'll ever see this? As the radar mentions, it's a pretty big oversight, and a pain for many internal and external developers. Will anyone on the Xcode team care to comment? There hasn't been a comment from them in the radar since October 2006!
On Mar 21, 2008, at 8:30 AM, Ladd Van Tol wrote: Don't hold your breath on this one. I filed a bug (3716243) on the same issue in 2004, and it was marked as a duplicate of an even older bug (2725744).
I have a simple metric for determining if Apple will fix an Xcode bug:
1. Does this bug affect Apple engineers?
2. If yes, fix bug
3. If no, do not fix bug
All kidding aside, I think Apple might benefit from deeper insight into how non-Apple engineers use Xcode. Not being able to pick dynamic/static linkage from the GUI is easy for Apple to ignore, because Apple can just ship the pertinent dylib with the OS. Similarly, the lack of support for non-Unix line endings in FileMerge is easy for Apple to ignore, because they don't port Windows apps very often.
Before this meme takes off, let me just remind everybody that Xcode is a software development project with the same kinds of constraints as any other: finite development resources, a legacy code base, a fervent and growing user base with an appetite for both bug fixes and new features. We have the added excitement of corporate imperatives to support hardware and OS development, like new OS releases, technologies, and platforms (such as the iPhone SDK).
Given all that, historically we've addressed 1,100 unique developer-originated bugs, but have a backlog of over 700 features and enhancements alone requested by developers, not to mention hundreds of bug fixes. Our dot releases tend to focus on bug fixes, polish, and upgrades to minor subsystems, while our major releases tend to focus on significant features, modernization and rearchitecture.
Often a seemingly minor enhancement or bug fix will be deferred because we know that its underlying cause is going to be eliminated in the changes planned for a future major release, and it makes more sense to use the available resources to fix other bugs in the short term.
We prioritize our work based on some pretty conventional criteria: - who and how many people does the bug affect - whether there's a workaround - is it newly introduced or longstanding (or so old it's an embarrassment) - will fixing it introduce risk in other places - will work now be obviated by future work in the same area
In the three specific cases above, the operative criteria are a) the workarounds are straightforward and b) the fixes all involve major rework we plan for the future, and we've chosen to spend our time delivering required functionality (like Intel support, refactoring, and an iPhone SDK) and fixing bugs with no workarounds or in areas we expect to last for 5 more years.
The key message here is just because we haven't addressed one particular bug of yours doesn't indicate that we don't value your bug reports or don't care about your workflow, but simply reflects the difficulty of fulfilling all known requests in any given release.
Chris Espinosa Manager, Xcode Core IDE |