[swift-evolution] Pitch: Replacement for FileHandle

[Maxim Veksler]

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 at 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 at swift.org> wrote:
>
>
> On Feb 15, 2017, at 2:25 PM, Charles Srstka <cocoadev at charlessoft.com>
> wrote:
>
> On Feb 15, 2017, at 3:11 PM, Itai Ferber <iferber at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> *_______________________________________________*
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/e4339256/attachment.html>