[Adium-devl] Gearing up for SoC

[Evan Schoenberg]

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.

> 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.

> 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.

>   - 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).
	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...
	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'.

>   - 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.

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