[Adium-devl] Meeting comments, 11-1-07

[Evan Schoenberg]

Hey, team! I got a bit of downtime now while waiting on some lovely  
ladies to go into active labor so's their babies can be caught by  
yours truly; apologies I couldn't make last night's meeting due to  
scheduling :(

Excellent meeting, particularly regarding the very exciting adium-vv  
stuff.  Some comments:
1. It'd really be good for extensive work on libpurple to be done on a  
mtn branch.  Some confusing talk went around regarding getting Alan  
'access' to pidgin's monotone repository.  It wouldn't be a problem at  
all for Alan to have the ability to commit directly to pidgin monotone  
in a branch designed for continued v/v work, but it also shouldn't be  
a problem to set up a repository on adiumx.com that allows distributed  
access to the pidgin one.  The point of a distributed version control  
system isn't necessarily offline access, though that is useful in some  
cases, but rather allows us to be full players in the developement  
process for while managing our work locally.

I think we should have a monotone branch of libpurple which  
corresponds to the code currently in use in Adium (that generally  
would mean a direct propagation to a particular release, but might  
potentially include other divergences or patches).  Branching within  
that repository would allow ongoing work to keep real version history  
and change tracking, and eventual merges to im.pidgin.pidgin (the  
libpurple 'trunk') would carry with them that full history as well as  
be able to take advantage of monotone's merging.

Thoughts?

2. We're going to end up increasing the download size of Adium; the  
changes to the build process have already done so. A quick glance at  
the Frameworks directory in the updated build dependencies branch  
versus trunk shows an increase of 3 or 4 mb, uncompressed, already.  
<explanation for anyone not following the progress on the changes to  
the build process> This is because the old Libpurple.framework  
utilized static linking of dependencies and therefore effectievly  
stripped any dependency code which wasn't used; the new setup has to  
keep the full library intact because it is unknown in what ways it  
will be used. That's a good thing for us, making our builds less  
fragile and future expansion to use other libraries much  
simpler.</explanation>

3. MSN voice/video: Alan mentioned the need for a DLL.  Is that how  
aMSN manages its video?

4. Mac-arena: Would you please write the upgrade code to rename our  
application support folder for Adium 2.0? :D

5. I have a longish email in process (prodded by Colin weeks ago!)  
which has kinda gotten stuck in the mental works regarding access to  
our new infrastructure (particularly Smew, the build box) because I'm  
not really sure what is best having not managed or helped manage a  
build environment before and I don't want to come across as sounding  
authoritative on a subject which I'm effectively making up as I go  
along.  Does anyone have experience handling access control for a  
medium sized group to a shared resource like that? If so... do you  
have any suggestions?

6. Let's get a 1.1.4 beta out and fasttrack to a release.  We could  
consider updating to the next.minor branch of libpurple for it, but  
I'm not aware of any major changes which affect us on it so am  
inclined to let a sleeping bird lie and push as-is.  The fuzzy user  
icon drawing is pretty weird; it'd be nice to fix it before release  
(at which point we could say we had fixed every known 10.5-specific  
bug) but I think it's more important to re-enable drag & drop,  
re-enable the contact image picker (now with the ability in 10.5 to do  
the various core image filters, live!), and behave properly with  
spaces, all of which we do with a release now.

Yours at Grady,
Evan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.