Re: Bug reports and documentation updates
Re: Bug reports and documentation updates
- Subject: Re: Bug reports and documentation updates
- From: Wade Tregaskis <email@hidden>
- Date: Thu, 24 Jul 2003 12:49:49 +1000
>
> Does it really matter if someone knows some tidbit about what might
>
> be in the next released?
>
>
Yes it can. It can get into regulatory issues with the SEC if people
>
are trading stocks based on implications of leaked info. It can kill
>
sales for a quarter while everyone awaits some change/release/addition
>
implied by a particular titbit. It can get Apple sued because the
>
license Apple has requires non-disclosure but the info leaked. And
>
more.
Buying or selling stock based on knowing whether a bug will be fixed or
not is probably not going to land anyone in court.
In the computing industry there are significant and regular advances
every few months. A good question is, does it really matter if you
know for sure that something new is around the corner? I expect new
products & upgrades in the near future, perpetually - I'd say you'd be
stupid not to. I'm not going to hold off buying something now on the
chance that something new is about to come out, because invariably it
is. But then there'll be something newer about to come out after that.
Where do you draw the line?
From all my experience with true end-users, they buy a computer as a
tool - a means to an end. They draw the line right here and now.
They'd only wait for a newer model if the current ones simply weren't
sufficient for their needs.
>
> If the bug reporting interface were tied into the ADC [and thus
>
> per-user authenticated],
>
>
It is. Try to file a bug without going through Apple Connect login.
>
You can't do it.
I wasn't aware they were on the same system - they're not integrated.
Which is what I was aiming at. I'm not aware of any distinction, in
the bug reporter, between me and anyone else. But in the ADC there's
quite a clear distinction - I'm a meaningless student developer, versus
the premiere and select members. More importantly, though, are the
individual accounts - information can be declared private on a per-user
basis.
>
> people could mark reports (or additions to) as private, and so others
>
> wouldn't be able to read them. That way 3rd party developer's could
>
> submit sensitive code demonstrating the problem, alongside public
>
> details of the problem. Other developer's don't necessarily need
>
> specific examples of the bug (they'll already have one, if they're
>
> looking at the bug report to start with) and Apple's developer's
>
> still have access to all the goodies.
>
>
You are proposing a technical solution to a non-technical problem.
>
The problem is bugs visible outside the "need to know" circle will
>
leak proprietary info. It has happened inside Apple between
>
development groups. It has happened in an attempt by the open source
>
team to implement a system very similar to what you propose. You can
>
wrap the problem with all the technology you want, but people are
>
fallible in their practices and judgment and the technology is not
>
going to correct that.
I find it sadly amusing that Apple are worried about internal leaks
between product teams. That really speaks volumes about their attitude.
I think perhaps my point did not come across properly... if you submit
private data, only you and Apple are privy to it. If it is leaked
outside this "need to know" circle, then that is an individual problem.
It is not a problem of the developer body at large.
In simpler terms, this is like banning CD burners because they /can/ be
used for music piracy. Denying it to everyone because of the
*potential* for someone to abuse it.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.