[Adium-devl] Throwing the switch

Evan Schoenberg evan.s at dreskin.net
Thu May 1 10:16:28 UTC 2008


On Apr 29, 2008, at 2:00 AM, Eric Richie wrote:

> I'm not in favor of switching over this close to SoC.

If we get it up and running, it may be a fairly clear choice whether  
we're comfortable enough to use it full time.  It would be great if we  
were; subversion currently sucks for maintaining multiple branches,  
though some hacks make that better, as we've been through multiple  
times before.  Some amount of confusion would be worth the ease of  
branch maintenance a modern DVCS would bring us.

If it's not 90% comfortable for us, having it ready would just mean  
that we re-import and do the actual switch when we're ready to do so.

GSoC is the addition of 3 students to the programming team.  We put a  
lot of effort into making their experience smooth and educational and  
so on, but the focus of Adium should not shift to center around them.   
They can adjust and learn to a reasonable but changing environment.

> I would however like to see a
> push for work from 1.4 on to be Leopard and XCode 3.0+ (including the
> current SoC students as it should open many more possibilities to
> them).

Half of Adium's userbase is on 10.4.  Most 10.5-only functionality we  
might use can be very easily made to run on 10.5 and ignored on 10.4.   
'course, if we were on a DVCS, it'd be reasonable for someone to have  
a long-range branch using 10.5-only functionality, merge pending us  
dropping 10.4...

>  I also wouldn't mind seeing a push to get the "Great Renaming"
> taken care of soonish but I think we may need some more discussion on
> those.

Colin, do you still plan to do this?

It'll need to be pretty automatic via XCode's refactoring features to  
be worth the time effort, to say the least.

>  But no, I don't think it would be a good idea to just push
> "throw the switch" right away.  I strongly suggest that we wait for
> the solution to be fully baked than to just go now for the sake of
> doing it.  I'm willing to wait if the result is a better product in
> the end.

With that, I do agree.  I don't like dropping history, and it  
shouldn't be necessary. I'd appreciate a little more detail about  
where exactly the import from subversion fails.  We can easily modify  
the repository to work around the problematic revisions; for example,  
we can split those dual-branch commits into individual commits at the  
subversion dumpfile level with minimal effort.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080501/e50088d2/attachment-0001.html>


More information about the devel mailing list