[Adium-devl] Gearing up for SoC

[Colin Barrett]

On Apr 24, 2006, at 6:15 PM, Evan Schoenberg wrote:

>
> On Apr 24, 2006, at 7:37 AM, Colin Barrett wrote:
>
>> I got my first email today from an interested SoC student (he was
>> asking about ticket #173 and such). Got me thinking about exactly
>> what we're going to do to handle the SoC applications, and then the
>> students themselves.
>>
>> Applications:
>>   - Should we set up a separate list, direct students' questions to
>> devl, or just have them email individual mentors directly.
>
> I think a list is a good idea. I've created an adium- 
> soc2006 at adiumx.com mailing list.
> If you are mentoring, please visit:
> http://adiumx.com/mailman/listinfo/adium-soc2006_adiumx.com
> and subscribe to the list.

*subscribed* :)

>> The first  option seems the best to me. I would like somewhere to  
>> discuss
>> applications though, but that may be best done on devl (or google may
>> provide us with something, who knows).
> Google provides a list for general SoC discussion which the admins  
> for each organization are subscribed to; it's not for discussion  
> within an organization.  I think adium-devl is a fine place for  
> discussion.

Alright. That'll only be a week period anyway. I think we can deal  
with that.

>> Accepted students:
>>   - I suggest setting up a Planet for them. Having blogs worked very
>> well last year for Gaim, I thought.
> That'd be awesome.  Zac is probably the best go-to man on getting  
> this rolling -- do you or does someone else have experience setting  
> up blogs and a Planet? I, too, liked Gaim's setup from last summer.

I've set up a planet, but see my other emails about that.

>>   - Should we give them their own branch, all branched from the same
>> r? We should consider how we're gonna handle that (e.g. externals,
>> merging back in, etc).
> 	Very strongly disagree with Chris's response of using patches.   
> Using a branch allows us to effectively look at a  single student's  
> changes and to take advantage of svn merge for moving such changes  
> to trunk then or at a later date.  Our student developers should  
> have access to version control, for sure -- the ease of branching  
> makes it a no-brainer.  I think we should have a branch for each  
> student.  We can allow merging from the branch back to trunk with  
> approval from the mentor, so if a student makes improvements to  
> core code we can bring that in for everyone to use (and we can  
> merge it into the other branches).  The process is easy so long as  
> we keep track of what revisions have been put where (though of  
> course svn log should be able to track it down for us, too, so long  
> as we use commit messages intelligently).

I agree completely.

> 	A shell script or two to automate merging changes into all  
> branches would also be a good thing -- we could even make a post- 
> commit hook script which takes any commit made to trunk and merges  
> it to the branches to keep them up-to-date.  Only hesitation about  
> that would be that we don't want a breakage on trunk to hurt the  
> students...

Perhaps some scheduled merge dates (sundays?) would help that. I  
strongly disagree with a post-commit hook script; this could leave  
conflicts in the student branches, which is bad karma.

> 	On the topic of branches, I would really like to have a 1.0 beta  
> out  before the students start in mid-May.  At that point, it'd be  
> reasonable to branch an adium-1.0 where changes specific to 1.0  
> went and have trunk go back to being 'unstable'.

I agree completely. I am going to make a big push to get the XML  
logging stuff in some kind of usable state this week, but no  
promises. School is coming to a close around then, which could  
interfere with that. But I'll do my best.

>>   - Because of the way Adium is set up, students may be interacting
>> with each others code. How should we handle this, as far as mentoring
>> goes? Should that mentor get both students? If that's not possible,
>> should the two mentors work in some kind of team, managing both
>> students? This is also kind of against what google has stated about
>> group projects (i.e. that you may not apply for a project as a
>> group), but I don't think it should be too much of a problem, since
>> the students are clearly working on two different projects, and just
>> collaborating on design issues (hopefully :o)
> I think that figuring out how to handle this situation in advance  
> is probably not necessary -- it depends on what code, and where,  
> and with what scope and timeframe, etc. We'll burn that bridge if  
> we come to it by discussing it on adium-soc2006.

Sounds like a plan. Mostly, I was just wondering if anyone could  
think of anything huge.

> -Evan

-Colin