GSoC improvements

[Jeff Mitchell]

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

Leo Franchi wrote:
>> Additionally, what Ian said in another branch of this thread is
>> probably true: Git will help here a lot.
> 
> 
> This does actually require us to be have already switched to git, and  
> as Ian said.... he needs to start working on scripty. I don't think we  
> can "assume" anything about us having git, until the work actually  
> gets done.

I too think that Git could be very useful to us in this regard, as we
can easily see changesets from a student compared to master.  We can be
using Git this summer, even if git.kde.org isn't ready.  I sent an email
a few days ago asking for opinions and only Ian got back to me, although
Leo got back to me earlier.  Both want open-source options (me too), so
this means either Gitweb hosted somewhere (I can easily host it, using
standard Git/SSH) or Gitorious.

I've grabbed the Amarok username on Gitorious (and Github, actually)
just in case we want to use it, and so that no one outside the project
can do so  :-)  I think if we are using one or the other, since they
have visibility, we should figure out whether to advertise it as
"developer branches, check it out!" or keep it low-key so people don't
assume it's the new home of Amarok development, as that will eventually
be git.kde.org.

Anyways, the only thing that needs to be done for either is simply for
people to give me their public SSH keys -- that's it.

There's one problem, which is the whole SVN/Git issue.  We can solve
this one of three ways.

One is that there is a "master" git-svn branch, and someone (or some
group of people) with access to this branch (maybe on pwsp, or on my
server) are responsible for merging in changes and pushing up to SVN
regularly or on request.  This is an OK option.

The other is that each mentor keeps their own "master" git-svn branch,
and is responsible for pushing approved changes from the students up to
SVN directly.  (Alternately students could keep git-svn branches but not
push to it unless the mentor approves the changes in their git branch.)
 I think either of these permutations is the best option.

The other way is simple, but loses git commit information, which is
simply to come up with a one-liner that does a copy of files from a git
tree to a Subversion tree.  This might make things difficult when things
like deletes happen.  This isn't as good an option.

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

iEYEARECAAYFAkmulbkACgkQANYdqNCuGCXQdQCguftFvpbTSdpLbV1Chx8T556Y
XiQAn3qkYwT7Wh89IAwj7BA7BBC1FAjT
=dbbC
-----END PGP SIGNATURE-----