GSoC 2016: applications open, deadline = Fri, 19/2

Hi,

The GSoC (Google Summer of Code) application for mentoring organizations
is now open. The deadline is Friday, February 19 at 19:00 UTC. That is:
very soon. New website here: https://summerofcode.withgoogle.com/. More
info about Git's previous GSoC iterations there:
http://git.github.io/SoC-2015-Microprojects/,
http://git.github.io/SoC-2015-Org-Application/.

I haven't been watching the list very closely the last few weeks, but I
didn't see a discussion on whether we shall participate this year, other
than "Starting on a microproject for GSoC"
(http://thread.gmane.org/gmane.comp.version-control.git/284958).

I think participating is a good thing, but it needs mentors, ie. people
and time. On my side, I'd be happy to give a hand to GSoC, but
unfortunately, I won't have time to properly mentor a student. I can be
co-admin, and can help someone to mentor, but only if this someone
agrees to do most of the work. Yes, I do realize that this sounds like
"we should do it, but someone else should do the work" ;-).

So, the first question is: are there volunteers to be GSoC mentors this
year? For those who never did it: mentoring means giving advices to the
student (partly done during the "microproject" phase in our
organization), participating actively in reviews (possibly doing some
first review iterations off-list to avoid overloading the list). On
overall, the goal is to make sure that some useful code is merged before
the end. It's a very enjoyable experience, it can be done with
reasonable knowledge of Git's codebase and community (no need to be an
old-timer), but it needs time to be done properly (expect to get ~10
iterations of each patch series, and spend hour(s) on each). And you get
a nice tee-shirt to show off with your geek friends.

If we have enough potential mentors, then the next questions are: who's
the admin? Work on the application itself, and on the list of ideas.

Cheers,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Hi Matthieu,

On Wed, 10 Feb 2016, Matthieu Moy wrote:

I think participating is a good thing, but it needs mentors, ie. people
and time.

I am available for mentoring. Stefan, it was really fun to co-mentor with
you, would you be willing to repeat the exercise?

Ciao,
Dscho

On Wed, Feb 10, 2016 at 3:09 AM, Johannes Schindelin
[off-list ref] wrote:

Hi Matthieu,

On Wed, 10 Feb 2016, Matthieu Moy wrote:

quoted

I think participating is a good thing, but it needs mentors, ie. people
and time.

I am people and I have time! ;)

I am available for mentoring. Stefan, it was really fun to co-mentor with
you, would you be willing to repeat the exercise?

Sure thing.

Ciao,
Dscho

Hi,

On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy
[off-list ref] wrote:

So, the first question is: are there volunteers to be GSoC mentors this
year?

I can co-mentor this year too, with you or someone else.
With you I think it will work out even if you have less time than last year.

Best,
Christian.

On 02/10, Matthieu Moy wrote:

Work on the application itself, and on the list of ideas.

One potential idea:

Make destructive git commands more safe for the user.

Some commands (e.g. git reset --hard, git clean -f, etc.) can
potentially destroy some of the users work.  Store the information
that we are potentially losing somewhere, where it's easily
retrievable by the user.

This should probably be hidden behind a new config variable
(core.iKnowWhatImDoingButIReallyDont or something better), as it has
the potential to really inflate the repository size (when storing
binary files that should be deleted by git clean for example).

It happened more than once that I thought I knew what I was doing, but
would have been really glad if git saved me from my mistakes.

I haven't thought this through much further than just the idea, so it
would be great to hear some opinions on it first.

On 17 Feb 2016, at 18:24, Thomas Gummerer [off-list ref] wrote:

On 02/10, Matthieu Moy wrote:

quoted

Work on the application itself, and on the list of ideas.

One potential idea:

Make destructive git commands more safe for the user.

Some commands (e.g. git reset --hard, git clean -f, etc.) can
potentially destroy some of the users work.  Store the information
that we are potentially losing somewhere, where it's easily
retrievable by the user.

This should probably be hidden behind a new config variable
(core.iKnowWhatImDoingButIReallyDont or something better), as it has
the potential to really inflate the repository size (when storing
binary files that should be deleted by git clean for example).

It happened more than once that I thought I knew what I was doing, but
would have been really glad if git saved me from my mistakes.

I haven't thought this through much further than just the idea, so it
would be great to hear some opinions on it first.

Coincidentally I started working on similar thing already (1) and I have
lots of ideas around it. I get endless requests at my $DAYJOB of messed
up Git repos where people just pasted stuff from StackOverflow without
a deep understanding of what they are doing.

If the lists agrees to take this topic for GSoC I would be happy to 
co-mentor it.

Cheers,
Lars

(1) using Git config hacks

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html