[Adium-devl] Burning Duck 2.0

[Evan Schoenberg]

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?

Peter wrote:
> * 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.
We need to do an audit of libgaim's logging and make sure passwords  
aren't logged (I believe in Jabber they currently are, for example).   
Even without being publically viewable, we have no business  
collecting passwords :)  With that done, a 50 line tail of debug  
logging could be really helpful for a lot of libgaim bugs.  This  
would be great for Adium and for libgaim itself (there are a ton of  
libgaim crashes which have been fixed because the Burning Duck gets a  
higher, more reliable volume of data for sporadic crashes than users'  
reports give the Gaim bug tracker).

<Trac integration>
The only problem with regularly linking Trac to the crash reporter in  
some way (i.e. with AdiumCrash(35849) or %35849 -- although it was  
suggested not to overload punctuation, something mirroring the #549  
ticket notation could be nice and simple) is that then crash reports  
need to stay around forever since trac tickets are intended to.  This  
in turn requires a crash database that has no scaling problems...  
currently, the couple thousand crash reports we get a day add up and  
make the search function sloooow (as mentioned).  It could use a purge.

<import of old crash tickets>
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".  Upgrade is our first line of defense...  
and while for historical analysis it could be interesting to have old  
crashes, I don't consider it too important.


Chris wrote:
>>  * Drop IM handles; we don't use them (if we REALLY need them, we
>> can request by email)
> 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.
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.


On Dec 20, 2006, at 11:05 AM, Phil Dokas wrote:

> It seems this was in response to having a mandatory email address.   
> Why not have the address be optional, mark it visually as such with  
> an explanation that mentions that submitting an email address can  
> help with debugging?
If there's a big problem with it being mandatory, I think it should  
still be there but be optional, indeed.  Honestly, we have enough  
crashes that a mandatory email address doesn't seem like a problem.   
yes, some people won't submit because they don't want to give us  
their address.  Many more people will put it in, and some of those we  
want to be able to contact with requests for more information or  
debugging.  Is there an outcry in #adium about the mandatory address?

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061220/d6ec4437/attachment-0001.html>
-------------- 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/d6ec4437/attachment.sig>