[Adium-devl] Burning Duck 2.0
Peter Hosey
prh at boredzo.org
Wed Dec 20 09:04:25 UTC 2006
Myself, David, Eric, Andrew W, and Elliott all contributed to this,
and Wengero supervised. What follows is the SEE document.
---
----- An Idealized And Argued About Look At A New Adium Crash
Reporter -----
== Big items ==
* Searching is currently sloooooow; fix it!
* Batch state changing
CFM: IFF (if and only if gosh —EH) we want to mark crashes fixed
(never ever used currently), then we need to be able to do it to
entire search results at once.
proton: if you're not using it as a bug tracking system it seems a
bit pointless really... better to have a ticket for the identified bug
CFM: agreed. Nuke it.
PRH: Linking it to Trac would make the existing close-as-fixed
system in the Crash Reporter redundant.
* Drop IM handles; we don't use them (if we REALLY need them, we
can request by email)
edr: sounds good
* 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!)
* 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.
* Include libgaim debug log
(not publicly viewable, obviously)
CFM: good idea, potentially large
EH: Yes please.
PRH: May require that we log to a file (perms: 0600) regardless, and
only rm it if the box is unchecked.
* Cross-referencing (date > 2006-05-01 AND version > 1.0b17)
* 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.
* 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
* 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.
* 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.
* 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.
== 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
== Searching ==
* by selector/function name
CFM: needs to only be in the crashed thread, naturally
proton: i'd give an option to let you search in other threads for
multi-thread interaction fun
* by library path+version (e.g. /foo/bar/baz.dylib 2.0.0)
CFM: not convinced of the usefulness of this one
* by bundle identifiers (extracted from the backtrace)
Example: 2 com.adiumX.adiumX 0x000c658f -
[ESAuthorizationRequestWindowController deny:] + 49
* by filename:line number (appears when one or more of the
executables — libgaim, Adium itself, etc. — has debug symbols)
* by architecture (ppc, ppc64, i386, x86-64)
* by OS version
* by Adium version
* by Adium build number
* by reporter (email address/trac login)
* ~~by Rosetta (Boolean)~~
edr: do any use rosetta since even .89 was UB?
PRH: Probably not.
* ~~by service?~~
PRH: Crash logs don't have services.
EH: why not?
PRH: Because crashreporter (the Apple process that generates crash
logs) does not know about IM services.
CFM: we can add info. Hell, we can add the entire sparkle dict in
easily enough, afaik.
* by service/account name
In format:
Accounts:
* AIM.jdoe
* GTalk.jdoe at gmail.com
* Jabber.jdoe at jabber.org
EH: I think service would also allow us to categorize and find
service specific crashes MUCH easier.
CFM: figuring out which service actually crashed would be harder
though...
EH: The previous asterisk seems reasonably possible.
* by Sparkle info
* by date (range)
== Display ==
Pretty much like the old one?
* 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…”)
* 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.
---
________________________________
\ Peter Hosey / prh at boredzo.org
PGP public key ID: 7AB26BAD (since 2006-01-01)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061220/8992a8aa/attachment.sig>
More information about the devel
mailing list