[Adium-devl] Burning Duck 2.0

[Peter Hosey]

On Dec 20, 2006, at 08:47:47, Evan Schoenberg wrote:
> Most of the BD2 plan sounds great.  Out of curiosity, is someone  
> volunteering to write this, is Jeff in the loop but quiet, or is  
> this in the musing stage more than the "someone will write it, what  
> should they write" stage?

The last of those.

> The only problem with regularly linking Trac to the crash reporter  
> in some way … is that then crash reports need to stay around  
> forever since trac tickets are intended to. … Old crashes are  
> generally not useful -- our automatic response to a bug report on  
> even 0.89.1 at this point is "try AdiumBeta and let us know if it  
> still happens".

My main reason for suggesting that the old crashes be kept around was  
exactly the persistency problem. We already have a few crash links on  
Trac that go nowhere.

Perhaps the crashes should be gzipped on the server?

Incidentally, I forgot to put this in the file (oops — bonehead  
mistake); it was in the IRC conversation:

23:33:41: <Mac-arena> Alternatively, we could store a UUID instead of  
a full crash log in the DB
23:34:00: <Mac-arena> and have the crash logs indexed by function  
name with a utility that actually knows how to read crash logs
23:34:27: <Mac-arena> (hooked up to the DB, to use PSQL's own  
indexing, so we'd add a row to the database that maps the function/ 
method name to the UUID)
23:34:22: <Catfish_Man> hm... that could be a good idea
23:34:43: <Catfish_Man> we lose fulltext searching, but gain way  
faster searching and possibly more useful searching
23:34:50:      <zac> write up what you guys want it to be and email  
it to -devl so other people can talk about what features it sould have
23:34:56: <Catfish_Man> that is a good idea
23:35:03: <Catfish_Man> maybe we can get jmelloy to give us his  
parsing code as well
23:35:28: <Mac-arena> We can write a generic crash log parser that  
reads all the information (metadata, method/function names, library  
paths and versions, etc.) and inserts them as rows into various tables.
23:39:11: <Catfish_Man> Mac-arena: actually, we can pre-parse clientside
23:40:06:      <zac> the problem with that is, whta if you want to  
change HOW or WHAT you parse *after* release?
23:40:12:      <zac> no, i say keep that part server side ;)
23:40:22: <Catfish_Man> heh, ok
23:40:35: <Mac-arena> Burning Duck is quite slow already. ;)

And I don't think I made this part clear in the conversation: The  
UUID would be the filename for the crash log. Something like $ 
(uuidgen).crash.log.gz. If we want to search for something that  
hasn't been parsed and inserted into the tables, we can use zgrep.

It occurs to me now that there are different versions of crash log.  
This could be solved by reading the version (Version: 4, for  
example), and sorting the files into directories by version. So we'd  
have:

	crashlogs/
		1/
			version1crashlog.gz
			version1crashlog.gz
			version1crashlog.gz
		2/
			version2crashlog.gz
			version2crashlog.gz
			version2crashlog.gz
		3/
			version3crashlog.gz
			version3crashlog.gz
			version3crashlog.gz
		4/
			version4crashlog.gz
			version4crashlog.gz
			version4crashlog.gz

> On the other hand, using IM requires catching the person online and  
> requires having a conversation. I've used the email addresses many  
> times; I've used the IM handles rarely.  I prefer email for this  
> sort of thing.

That's exactly my motivation for suggesting (a) requiring emails and  
(b) dropping IM handles.
________________________________
\ 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/2c618bab/attachment.sig>