GSoC improvements

[Jeff Mitchell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nikolaj Hald Nielsen wrote:
>> No, the alternative is that students commit faulty or poorly designed
>> code and no one notices until days or weeks later when the code is
>> already built more upon.
>>
>> This is what we're trying to avoid. :) I agree with the Lydia and this
>> thread in general, we do need an explicit review process.
> 
> Having the student commit directly to trunk is _not_ an excuse for the
> mentor to not review it. I actually think that having the mentor
> approve it in a separate branch is a bigger risk as other developers
> will start to get into a "oh, that must be ok as it has already been
> reviewed by the mentor" mindset. Also the mentor might miss serious
> issues in any case, in which case the pre commit review makes no
> difference.

I don't see why you think that having the code committed directly to SVN
will be any better.  There, you run the risk of the mentor not checking
the code in addition to everyone else.  At least if it goes through the
mentor first we definitely get one set of explicit eyeballs on the code.

"That must be ok as it has already been reviewed by the mentor" is just
a matter of policy.  Our policy should be to treat all commits equally
in terms of eyeballs (i.e. they should all be getting them); those
coming from the students should just have to go through a first round of
checkups (the mentor) first.  After that it should be subject to some
normal review policy, which could include using Crucible to have two
more devs sign off on it, or some such thing.

> Other issues I see is that mentors also have a life and might be away
> for a few days or a week (on holiday for instance) during this time,
> the student cannot get any code, unless someone else takes over
> reviewing the branch (who is not as familiar with the project)

This issue already exists with SVN, and using Git branches doesn't make
it any worse.

> And finally, and perhaps most of all, this is adding another layer of
> indirection to the entire development process, making it harder to
> keep track of what is going on.

Why is it harder to track?  Commits should be pushed from Git to SVN
regularly, it's just a matter of keeping it isolated while major changes
are being developed.

This isn't unlike the use cases we full developers have, where people
have used git or git-svn branches because they need to affect a lot of
files and want to not only be able to branch easily but be able to
ensure that a particular branch is in a sane state (while keeping their
interim work) before pushing it all up.

- --Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkmuv/MACgkQANYdqNCuGCUTawCeIpN6JbCm9Bfvrk1aAN9XZIRt
Q1YAniLe8Fm8JJ/4QMzxvjuLyM7ddEyu
=DA4O
-----END PGP SIGNATURE-----