[swift-evolution] Pitch: Replacement for FileHandle

[Derrick Ho]

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 at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/be9c71c8/attachment.html>