I agree that the current state of bug reporting through radars is unmotivating.
We file these bug reports and have no idea if it even made a difference. After seeing this many times we just don't bother with bug reports. Sure I understand that internally apple uses duplicated issues to show how often an issue is happening. I guess those numbers motivate an apple engineer to work on it. Well guess what, those numbers could motivate every non-apple developer as well! We want to know that our "vote" counts! Maybe the reason is that apple doesn't want to expose to the world that a bug exists and therefore keeps it a secret. It is hard to keep bugs a secret because eventually someone will blog about it or talk about it in a public MAILING LIST. I would very much like it if we could see the original bug report and references to the duplicate reports so we know that our report made a difference. Are there down sides to exposing bug reports to the public? (Sorry for going off topic as well) On Thu, Feb 16, 2017 at 8:09 AM Nick Keets via swift-evolution < swift-evolution@swift.org> wrote: > I’m going OT here, but even though I understand your reasons, you need to > acknowledge that for developers the rational thing to do is to not file > radars at all. > > Any bug fix will get released at best a few months later and you can only > actually take advantage of it a few years later (if you care about > supporting older versions). More realistically we are talking 3-4 years of > having to work around it (in the best cases). This is a lot of work (with > almost zero feedback) for some far future benefit that probably will not > even be relevant to you then. > > So to me, when an Apple developer asks me to file a radar, it feels like > they are asking me to do their job. > > I’m sorry for the off-topic rant. > > > On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoa...@charlessoft.com> > wrote: > > On Feb 15, 2017, at 3:11 PM, Itai Ferber <ifer...@apple.com> wrote: > > > FYI, Tony is the manager of the Foundation team. :) > We care very much about making sure that the experience of using our > framework is a positive one — the more Radars we get, the better we can > prioritize improving APIs that are not working as well as they could be for > our users. Even if the Radar gets duped to an existing one, thats one more > +1 for that Radar saying "this is a problem". > > Yeah I know, but it’s a frustrating experience, spending a half hour > writing a detailed bug report (sometimes with videos attached to > demonstrate the issue), just to effectively do the same thing as spending 5 > seconds to hit the +1 button on most issue trackers you come across. > > Especially since you never find out what happened to the original bug > report. You can see if it’s open or closed, but did they fix it in some > internal build? Did they decide it “behaves correctly?” Did somebody just > skim your report, and mistakenly attach it to some other, unrelated issue? > There’s no way to know. > > I will search for your old Radar, but in any case, please do file a new > one about this, and about any other issues you have, because we are indeed > listening. > > I was pretty sure I'd submitted something way, way back in the misty days > of yore, but I can’t find it. I’ve filed a couple of new ones: > rdar://30543037 and rdar://30543133. > > Charles > > > Thanks for filing these. > > Sometimes, for process reasons, we do indeed mark bugs as dupes of other > ones. Usually the polite thing to do is to dupe to the earliest filed one. > Sometimes this comes across with an appearance of not caring to the filer > of the new bug, but our intent is simply to consolidate the reports we have > so that we know that the issue is serious. > > We do not make API changes without going through a vigorous review > process, to avoid churn for the many clients above us. The flip side is > that this can take some time. I’m sure you understand that all software > engineering is about tradeoffs. > > All of that said, we’ll take a look at these and see what improvements we > can make here. As I said, I’m not a fan of exception-based API. > > - Tony > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution