Zealots (WAS Unacceptable and abusive comments needs immediate solution from Google)

by Mark Murphy » Fri, 10 Apr 2009 08:10:03 GMT


Sponsored Links
 


Since I suspect that's aimed in my general direction, let me be clear:

Google developers can "make bugs". Considering how many they have
pointed out on these lists, I suspect they'd be the first to tell you
that they "make bugs".

You have reported several bugs on these lists. As I recall, for these,
you indicated, in no uncertain terms, that if they affected you, they
must affect everyone, and that they are clearly bugs in Android proper
with no other possible cause.

I don't recall in any of those situations questioning whether the
symptoms were real. I asked for more evidence on the claims that they
affect everyone, that they were unequivocally bugs in Android proper,
plus for ways to reproduce the problems. The latter is the most
important, because no matter how the symptoms are caused, without
reproducible scenarios, fixing them is well nigh impossible.

In some cases (e.g., force-close-after-update), such evidence has
arrived, at least on the first two points. If we're lucky, the same
thing that causes this problem is what causes the similar force-close
triggered by changes to the AndroidManifest.xml file, that somebody
reported, I reproduced, and I opened an issue for. I doubt they're the
same thing, but one can only hope, since reproducing
force-close-after-update is obviously difficult.

In some cases (e.g., "TERRIBLE BUG"), evidence definitely points to a
bug in the build tools, though no evidence has arrived that indicates it
is currently affecting every Android developer. And, IIRC, we still
don't have a reproducible test case.

In some cases (e.g., takes-15-seconds-to-pick-up), we have neither
evidence of a widespread phenomenon nor conclusive evidence of a purely
OS problem. In this specific case, I'm still backing my theory that it's
out-of-spec hardware that is reacting poorly with a new driver in RC33.
Heck, if I were HTC, I'd buy your phone off of you, just to have a
sample of the problem on hand. Alas, I am not HTC, nor do I play HTC on TV.

If I'm a zealot for asking for evidence to back up sweeping claims and
broad generalizations, and for hoping for more civil discourse than
sometimes is seen on these lists, then I'm comfortable with that.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com  |  http://twitter.com/commonsguy 

Android App Developer Books:  http://commonsware.com/books.html 

--~--~---------~--~----~------------~-------~--~----~



Zealots (WAS Unacceptable and abusive comments needs immediate solution from Google)

by Incognito » Fri, 10 Apr 2009 11:23:08 GMT


 Hahahaha. Pretty funny. It most feel like people throwing stones at you and the 
e-mail below is just the involuntary reflex to raise your hands to shield 
yourself.







Especially when
Google are so strongly supported by so many zealots who think Google
devs can't make bugs and it's all the developers' fault.

Since I suspect that's aimed in my general direction, let me be clear:

Google developers can "make bugs". Considering how many they have
pointed out on these lists, I suspect they'd be the first to tell you
that they "make bugs".

You have reported several bugs on these lists. As I recall, for these,
you indicated, in no uncertain terms, that if they affected you, they
must affect everyone, and that they are clearly bugs in Android proper
with no other possible cause.

I don't recall in any of those situations questioning whether the
symptoms were real. I asked for more evidence on the claims that they
affect everyone, that they were unequivocally bugs in Android proper,
plus for ways to reproduce the problems. The latter is the most
important, because no matter how the symptoms are caused, without
reproducible scenarios, fixing them is well nigh impossible.

In some cases (e.g., force-close-after-update), such evidence has
arrived, at least on the first two points. If we're lucky, the same
thing that causes this problem is what causes the similar force-close
triggered by changes to the AndroidManifest.xml file, that somebody
reported, I reproduced, and I opened an issue for. I doubt they're the
same thing, but one can only hope, since reproducing
force-close-after-update is obviously difficult.

In some cases (e.g., "TERRIBLE BUG"), evidence definitely points to a
bug in the build tools, though no evidence has arrived that indicates it
is currently affecting every Android developer. And, IIRC, we still
don't have a reproducible test case.

In some cases (e.g., takes-15-seconds-to-pick-up), we have neither
evidence of a widespread phenomenon nor conclusive evidence of a purely
OS problem. In this specific case, I'm still backing my theory that it's
out-of-spec hardware that is reacting poorly with a new driver in RC33.
Heck, if I were HTC, I'd buy your phone off of you, just to have a
sample of the problem on hand. Alas, I am not HTC, nor do I play HTC on TV.

If I'm a zealot for asking for evidence to back up sweeping claims and
broad generalizations, and for hoping for more civil discourse than
sometimes is seen on these lists, then I'm comfortable with that.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com  |  http://twitter.com/commonsguy 

Android App Developer Books:  http://commonsware.com/books.html 





      


--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Other Threads

1. SurfaceFlinger and Layer buffers

Hi Mathias!

Can you outline how LayerBuffers are intended to work in SurfaceFlinger.
- Are these buffers still allocated by SurfaceFlinger?
- Does it enable for example multiple buffers to be queued for display
(rather than a double buffered approach).
- Is the intention of them to provide support for streams of video
data (e.g. from decoded video).
- Is the intention that these buffers will get locked/unlocked and
drawn to by a client, or does Android differentiate between surfaces
used for general rendering and those used for say video playback.
- With respect to video playback does Android expect to be able to say
decode a video frame and then allow for example some rendering to be
added to the buffer before being presented for display?
- Can you describe how video playback relates to SurfaceFlinger?
- What mechanisms are used to ensure that video frames are displayed
at the correct time by SurfaceFlinger?

Thanks.

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: 

2. How could I know the detailed capability of one content provider?

More specific, I wan to figure out all the Calendar Provider's
capabilty I could use.

BRs
He


--~--~---------~--~----~------------~-------~--~----~

3. WebView loadData and XML Parsing Question

4. How to change the Userinterface-Surface?

5. Taking OFF the "Missed call/s" notification

6. Is Google focused on Android?

7. Could Android power a phone like this...