[Adium-devl] Burning Duck 2.0

[Christopher Forsythe]

Albeit we've asked Jeff to fix this stuff before without getting some  
of it done, comments inline (stuff I agree with I'm just snipping).  
It also wasn't clear until about halfway down this email that this is  
a proposal for a new crash reporter, instead of just stuff we want  
Jeff to fix about the current one. Anyhow:
On Dec 20, 2006, at 3:04 AM, Peter Hosey wrote:

> Myself, David, Eric, Andrew W, and Elliott all contributed to this,  
> and Wengero supervised. What follows is the SEE document.

<snip>

>
>  * Drop IM handles; we don't use them (if we REALLY need them, we  
> can request by email)
> 	edr: sounds good
>

The reason we have it is for:

1) People who don't have email addresses

2) People who don't want to give us theirs but want to give us a  
valid contact avenue.

If we drop im we should drop email. But it would make more sense to  
drop email since we *know* that the person will have an im account if  
they are using Adium.


>  * Require an email address
> 	Promise not to spam them or sell the address
>
> 	CFM: still not convinced this is a good idea. I think "email  
> address OR something to search by"
> 	proton: No need to require any idenfitication unless they want to  
> hear back, could be useful to be able to data mine the crash  
> information that people will give if no info is required
> 	edr: We kinda need something just in case, otherwise we get some  
> made up something and can't contact them if we need to.
> 	CFM: I don't think we should be requiring the ability to contact  
> them; that should be something they can allow if they want.
> 	PRH: But what if we need to contact them? Not all crashes happen  
> to everybody, but they still ought to be fixed if there's anything  
> at all we can do about them. (I'm looking at logging/LMX crashes.)
> 	CFM: I think we get to pick between losing crashlogs and losing  
> the ability to contac them though; some people will just hit "don't  
> send" to avoid submitting an email
> 	edr:I'm torn, I agree with both perspectives, but ultimately I  
> think I prefer having some way to follow up over nothing
> 	proton: crash reports can still be useful to be able to data mine  
> without any other information. you can see if a crash is common,  
> has happened to other people etc. I know that Apple's stuff doesn't  
> require this (and in general they don't look at the descriptions),  
> they can look if they can't reproduce or work it out.
> 	PRH: Apple's Radar does require an Apple ID. ;)
> 	CFM: As does our Trac
> 	proton: yep, Radar != crash reporter
> 	PRH: Alternatively, we could yield a crash URL to them that they  
> can check back on. We could have the ability to leave notes for  
> them. (Maybe with RSS!)
>

See my above comments.

>  * Trac integration?
> 	Users would be able to submit crashes/read their own crashes with  
> their Trac l/p, alternatively to their email address.
> 	EH: Read my mind. I think that's the most elegant way to deal with  
> it. We could potentially link crash logs to tickets?
> 	edr:agreed
> 	PRH: That would be a *lot* of tickets.
> 	Though a backtrace-hashing system would be able to link a ticket  
> to multiple crashes.
> 	proton: no need to actually log tickets for each one
> 	EH: Not every crash log gets a ticket, just be able to link  
> specific crash logs to tickets as additional troubleshooting help?
> 	PRH: Like we do now. ;)
> 	PRH: ~~We could have a adium-crash: URL scheme with a simple app  
> that maps it to a crash log URL and launches it in $BROWSER. (rdar:- 
> simulation)~~
> 	EH: Well, automatically from within crash reporter.
> 	proton: well radar is actually a full GUI app.... but I don't see  
> what a URL scheme adds other than "nifty"
> 	PRH: I know ;)
> 	It prevents users from saying "Hey, I tried to click on that crash  
> URL you posted in my ticket, but it said I need a login/password"
> 		(Although I suppose that if we made crashes viewable by anyone,  
> that wouldn't be so much of a problem)
> 	CFM: it replaces "wtf login" with "wtf not a valid url"
> 	PRH: Truth.
>

I'm heavily against this, I think we should continue to keep the two  
separate. At the very least this would make for a lot of complication.


>
>  * Import from ye olde Crash Reporter
> 	EH: zuh? why?
> 	PRH: Keep old statistics, and also so we can migrate crash URLs  
> for old crashes over to the new URL format.

Crash reports get dropped from the database at some point when we  
deem them useless. Stats might be neat, but they do cause slowdowns  
in queries when you get uber thousands of them apparently.


>  * Alternative: Second link format for old crash reports
> 	http://burningduck.adiumx.com/oldcrashes/12345
>    * Handle as redirect, or
>    * Copy all data from visualdistortion, filed in the oldcrashes  
> folder
>

We can always just look at the old crash reporter, doing this would  
add to complication.


>  * New location
>    * crashes.adiumx.com? —PRH
>    * crashlog.adiumx.com? —EH
>    * boomgoestheduck.adiumx.com? —PRH
>    * logs.adiumx.com - EH
>    	PRH: Bad; people will think we mean transcripts and are keeping  
> those for our private reading.
>    	EH: Aren't we? ;D
>    	PRH: Not as far as you know, new committer ;)
>    * burningduck.adiumx.com —EDR
>    		CFM: seconded
>    		PRH: Thirded.
>    		EH: Worksforme.
>


Or we could use adium.org for it :)

>  * Random Thought: With so many new things, maybe some sort of dev- 
> portal to access our new toys?
> 	PRH: ?
> 	EH: Well, Trac is already pretty crowded just dealing with tickets  
> let alone  attaching crashlogs / crashlog management?
> 	edr: we already have something setup on visualdistortion for that  
> stuff, so we'd probably just migrate to where ever the new stuffs  
> are going
> 	PRH: I don't think we need to actually go through Trac to view the  
> crash logs; I'm envisioning something that will reach out to Trac's  
> accounts DB, but not actually be the same front end. You'd go to  
> burningduck.adiumx.com to pore over them, not trac.adiumx.com.
> 	EH:  Same logins?
> 	PRH: Aye. The prototype of our magic Adium ID system.
> 	EH: Sounds beautiful.
> 	edr: sounds good, I'd prefer not to add crashlogs to my plate in  
> trac ;)
> 	EH: Agreed 100%.
> 	EH: Another goal: Thou shalt not let crashlogs slow down Trac any  
> more than it 	is.
>

The trac accounts "database" is not going to be exposed in that way  
Peter.

>  * AdiumCrash macro in Trac
> 	Example: My Adium crashes when I twiddle the feeblewatzit.  
> Reported as AdiumCrash(0123456789).
> 	Expansion: … Reported as [http://burningduck.adiumx.com/crashes/ 
> 0123456789 crash number 0123456789].
> 	EH: Even better, $0123456789 ?
> 	PRH: Overloading $ is bad. What if you want to offer a $0123456789  
> bounty for the bug? ;)
> 	proton: then i'll fix it damn fast :-)
> 	EH: &? :D
> 	PRH: Better not to overload existing punctuation. Besides, Trac  
> already has a macro system — TracNav(TOC), for example.
> 	proton: does that mean we get to make up new punctuation?
> 	PRH: Sure. Submit a draft to the Unicode Consortium. :)
> 	EH: We should call it the feeblewatzit.
> 	CFM: they should definitely be extra-planar characters
> 	PRH: “To reference a crash log in your ticket, type a feeblewatzit  
> followed by the crash number.”
> 	EH: Worksforme. I just think a shorthand for referencing certain  
> crashlogs would be handy. #6245:@27342
> 	PRH: Or: #6245 (AdiumCrash(27342)
> 		Which will become: #6245 ([http://burningduck.adiumx.com/crashes/ 
> 0123456789 crash number 0123456789])
> 		Which will become: #6245 (crash number 0123456789)
> 			EH: hyperlink?
> 			PRH: Aye.
> 			EH: not as pretty as our ticket numbers, very hard to reference  
> a 					crash in IRC, which we do a lot with tickets.
> 			PRH: No problem there. !crash 0123456789
> 			PRH: It'd be a simple extension to TownCrier. Either case-and- 
> paste or another line in some conf file somewhere.
> 			PRH: (Hello Andrew!)
> 			EH: I'm just worried about confusin where if I say 6245, do i  
> mean 					ticket or crashlog, but I'm being dumb I guess. :D
> 			PRH: You could say #6245, and then we (being all Trac users)  
> will all know what you mean.
> 			EH: I will personally adopt C#### for crashlogs, and you can't  
> stop 				me so there!
> 			PRH: Could just say AdiumCrash(####), and then you'll be in the  
> habit for the next time you go to enter that into a Trac form. :)
> 			EH: IRC script ahoy I suppose.
>

Adds to maintenance time, I'd be hesitant to do anything like this  
until we have a perfect crash report on its own.

> == Statistics ==
>  * Most Common Crashes By Version
>  * Crash Rate By Version
>  * anything else here? Correlations perhaps? i.e. All the most  
> common crash users used MSN
>  * Raw SQL query with automatic graphing? (Handy for e.g. Adium  
> version)
>  * Most common selectors/function names in backtraces
> 	Exclude obvious ones like objc_msgSend, mach_msg_trap, etc.
>  * Number of crashes over time
>

I think correlating stats would be neat, but would it slow things  
down for people doing searching?


> == Searching ==
>  * by library path+version (e.g. /foo/bar/baz.dylib 2.0.0)
> 	CFM: not convinced of the usefulness of this one

Do we really need this?



>  * by architecture (ppc, ppc64, i386, x86-64)
>  * by OS version
>  * by Adium version
>  * by Adium build number

I can see these for stats, but search?

> == Display ==
> Pretty much like the old one?

The old one was hard to read in a lot of ways, it'd be nice if we  
could get some kind of newer template for it.

>  * Hide email address and description for those not logged in
> 	descripton may contain trade secrets (e.g. “I clicked on the  
> Secret Leopard Menu and…”)

I don't know if I like people being able to just look at crash  
reports all willy nilly to be quite honest. It's a developer  
resource, not something that users can use. If we however let them in  
then they are going to be doing all sorts of random things, like  
searches that will take a while and then cause resource problems,  
potentially.

So what's the argument that non-devs/contributors should be able to  
access crash reports other than their own?

>  * Conversely, show crash log regardless of logged-in-ness
> 	proton: a crash log can still contain potentially sensitive  
> information -- backtrace with some secret new feature metnioned...
> 	CFM: what if we allowed users to login using the info they provide  
> and view only their crash's info? That way they can link to them  
> without the info bbeing public
> 	edr: not sure I follow...
> 	proton: what might be nice is some sort of "Adium ID" that let  
> people log into multiple things: forums, trac, crash reporter  
> system. then if people want to find out more they can offer one
> 	CFM: This can be done via XMPP interestingly enough :)
> 	proton: what *can't* be? :-P
> 	PRH: What can't?
> 	PRH: Suppose we had two checkboxes:
> 		[ ] Make description publicly viewable
> 		[X] Make backtrace publicly viewable
> 	proton: too much for a normal user. better to have an option to  
> allow someone "if you have an adium ID, you can enter it here...  
> otherwise, just click submit"
> 	EH: Maybe an option for a developer/tester log versus user log,  
> developer/tester logs would include descriptions for more thorough  
> testing? :\
> 	CFM: KISS. We don't need zomg epic crash reporter. The stats and  
> better searching will be two-three orders of magnitude improvement.
> 	proton: exactly! i think if you want users to be able to see info  
> about their crashes then a login or email could be added.  
> otherwise, just an optional what were you doing field, and the  
> crash log
> 	EH: Something about an Adium ID makes me feel warm and fuzzy inside.
> 	PRH: Maybe even have a preference for them to select their own  
> feather color!
> 	proton: and if we ever actually had absurd amounts of money and  
> time you can use it for an adium jabber service etc ;-)
> 	CFM: and webbed foot webbing radius, and beak size, and feather  
> gloss levels in all weather conditions with full physics simulation
> 	PRH: "My beak size is 12 inches huhuhuhuhuh"
> 	proton: "Mine is 12 feet!"
> 	EH: Don't forget wing size!
> 	PRH: There'll be some emu-looking ducks on the Adium ID system…
> 	EH: I still have dibs on the Dr. House duck.
> 	PRH: I'll have the BOFH duck and we can duel. ;)
> 	EH: because naturally, we get special ducks on this system.


I guess this goes along with the sentiment of my question above :)

Good job guys.

Chris