My GSoC2014 retrospective

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

So, GSoC 2014 is over, and it's time for me for a retrospective too.

As a reminder, Git participated in GSoC a number of times, but we were
not happy enough with how it went and did not apply in 2013. This year,
we thought we would hopefuly be better at mentoring students, and gave
one more try. It was my first experience as a GSoC mentor, although I
supervised students my engineering school contributing to Git as a
school project several times.

On overall, Git selected 3 students, one of them did not send anything
to the list and failed the mid-term. Fabian worked on rebase -i
improvements, send several versions of his patch series, but the code
did not reach pu (yet?). I mentored Tanay, who worked on git_config
improvements with the help of Ram. As Tanay wrote in his retrospective
[1], there's a reasonable amount of code merged (next or pu). All the
objectives of the project have not been reached, but I still consider it
as a relative success. I prefer by far having this situation than having
everything half-done and nothing merged.

  [1] http://permalink.gmane.org/gmane.comp.version-control.git/256458

I think the following contributed to this (I'll talk about my
experience, don't try to see a comparison with others or any
over-generalization):

Microprojects
-------------

Microprojects were a really, really good idea. Far better than selecting
students only based on their proposal on melange and a superficial
discussions in the comments below the proposals. And not only for
selection: students learnt the contents of SubmittingPatches before
starting the project, so that was one less thing for me to teach as a
mentor, and less opportunities for mistakes in the first iterations.

On-list interaction
-------------------

According to my email archives, there are 106 threads where I sent an
email to Tanay, 83 of which happened on-list (and 64 are followups to a
PATCH). The off-list exchanges were essentially quick reviews of draft
series, and short messages to give an advice.

I think its very important to have this on-list interaction for many
reasons. It's good, make sure everybody has an opportunity to give his
or her opinion about the project soon (as a mentor, I can obviously be
wrong, and the sooner someone notices it, the less time lost). It's good
for the student, because GSoC is all about interacting with a community,
not just with a mentor. And, well, it has to be good because this is
how we usually work here.

OTOH, we should probably have exchanged a few emails in private between
GSoC mentors and admin. I wasn't really aware of what other students
were doing except what they sent to the list, and it could have helped
to know a bit more about how others were doing.

Also, I insisted with Tanay that he should introduce himself on the
list, and remind people that he was working as a GSoC student when he
sent his first patch. I realized how much this was important when I
discovered in a private conversation that Junio did not know that
Fabian's series was sent as a GSoC project. While I don't think "I'm
sending this patch as part of my GSoC" should be equivalent to "please,
merge this even if the code is not good, I'm still a student after all",
I think is helps reviewers to know about GSoC, if only to better advise
the student.

Code merged ASAP
----------------

I think Tanay and I did a good job at getting some code merged early. We
did bother Junio a bit with series depending on each other, but we could
send code by relatively small series, and prioritized "finish first
series" over "start new ones". Of course, reviews take time, so we still
had several series in parallel, but splitting the work like this allowed
some code to reach master early, while part of the work is still
unfinished.

We all hope that GSoC students will remain part of the community, and
it's tempting to think that unfinished code isn't a problem because we
will have time to finish it later, but I think it's risky. My motto for
this kind of projects (I do the same with Ensimag students): hope that
students will keep contributing after the end, but don't rely on it.

Mentoring takes time
--------------------

I knew it (and actually, I was initially reluctant to be a mentor for
this reason), but I did enjoy the experience and happily spent a lot of
time and energy on it.

Most series needed many iterations, and we couldn't have reached the
quality required to get in git.git without fast and detailed reviews. I
did my best to review the code ASAP when a series was sent, and
fortunately the list, and Junio in particular, was very supportive.
Thanks a lot to everybody who contributed!

Still, I think it should have taken less iterations to get the final
result. But I do not know what we could have done better for that.

In the end ...
--------------

My goals with the GSoC were essentially (unordered):

* Teach cool stuff to a student (for those who missed it, I'm a teacher
  in another life ^^)

* Get useful code in git.git

* Attract new long-term contributors

* Have fun

I think each of them is satisfied. The future will tell us if the third
one is actually reached, but Tanay's motivation was also to start
contributing on a regalar basis, and I hope we all motivated him to do
so!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]