Hey GSoC mentors! Before GSoC students with our project start
committing their work into our repo, I wanted to suggest some
organizational guidelines to streamline the workflow and also secure
trunk from breaking with potentially experimental code. Namely, I was
thinking maybe we should create either a single GSoC dedicated branch,
and appropriate subdirectories therein for each of our students (e.g.
/branches/GSoC2007/pipping_universal), or separate, well defined
branches for each (e.g. /branches/GSoC2007_pipping_universal),
depending on consensus.
In any case, I believe we should keep GSoC produced code out of trunk
until projects are called completed, both to secure trunk from breaking
but also for accountability of the project and the student's progress
(if everything goes into trunk it becomes easy to mix things up). If we
go this route, which I strongly recommend, students would, of course,
have to handle keeping their branches in sync with trunk when
appropriate, so that merging back into trunk upon project completion is
as painless as possible.
Thoughts?
-jmpp
PS: Elias already made a commit to base from his GSoC work, r24148, so
he would have to back that one out and commit it to his branch (or
sub-branch).
PPS: Someone (Paul?) please make sure Eugene Pimenov gets involved in
this discussion, I couldn't find any mailing information for him
anywhere (actually, he should be required to sing up to this list and
to mp-changes if he's going to be committing to our repo, I couldn't
find him on either list's rooster).
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
