Please take off-topic discussion elsewhere. Thank you.
> On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution > <swift-evolution@swift.org> wrote: > > An off-topic suggestion on radar bugs: > > Instead of closing as "dupe" why not call it "merged" into a known issue ? > > Same technical result but very different IMHO user experience that allow > communicating to the reporter that his bug hasn't simply been wrote-off as a > "plus 1" but was combined into a very long story of use cases and examples to > be considered while working on finding the optimal balance solution for the > issue at hand. > On Fri, 17 Feb 2017 at 1:16 Zach Waldowski via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I can scarcely think of a less productive or more disrespectful thing to do > in a thread chock full of Apple engineers actively trying to help you out. > They're just humans, led by other humans. They can't divine the presence of > issues, just like they can't divine the priorities of individual tasks > without a holistic view of them. It would be far more productive to figure > out how we can get the changes we want done in a public release of software > as soon as possible. Everything else is extraneous. > > Best, > Zachary > > On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution 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 <mailto: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 <> 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 <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 <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 <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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
