> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoa...@charlessoft.com >> <mailto:cocoa...@charlessoft.com>> wrote: >> >>> On Feb 15, 2017, at 3:11 PM, Itai Ferber <ifer...@apple.com >>> <mailto: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 >> <rdar://30543037> and rdar://30543133 <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,
At the risk of getting off-topic, I think it would defuse a lot of developer frustration around that to just show the status (open/fixed/wontfix/correct) of the root bug. Filed radar 30551245 suggesting as much ;-) > 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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
