Starting on a microproject for GSoC

Starting on a microproject for GSoC

[Moritz Neeb]

Hi git developers,

the next Google Summer of Code is not too far away. I expect git to
apply for it and hopefully have some student spots which in turn I plan
to apply. It was recommended elsewhere and on this list as well, that it
is beneficial to engage with the community early, that's why I am
writing to you already now, before all this formal stuff has begun.

Before I may introduce myself: I'm a Computer Science student in
Germany, coming towards the end of my Masters. I am an enthusiastic git
user that's why I'd like to give something back. This would be my first
time to actually contribute to a FOSS project and I am quite excited
(also a bit frightened ;)).

As the list of available microprojects 2016 is still to be created, I
might need your help in finding a project to work on. I started to dig
through the archives along items of the list of 2015 [0] and so far
found out the following:

The first task, to make "git -C '' cmd" not to barf seems to be solved.
I tried it with "git -C '' status" at least. I could not find the
related patch, maybe it did use other keywords. I would be interested.

The second task, to allow "-" as a short-hand for "@{-1}" in more places
seems to be still open for reset, although someone almost finished it
(cf. $gmane/265417). I suppose just fixing/revising this would be kind
of a too low hanging fruit? More interesting (also because I am a bit
earlier) might be to unify everything, as suggested by Junio in
$gmane/265260. Or implementing it for another branch command, e.g. rebase.

The other tasks I did not yet dig into.

If all of that is considered as not relevant, I might just go for a
newer idea, like converting strbuf_getline_lf() callers to
strbuf_getline(), as suggested in $gmane/284104.

Any thoughts?

A question regarding the process of "taking a task (or bug)" in general:
Is it solely organized through the mailing list? Suppose I start to work
on something, should I announce it to not risk work duplication? Does it
happen often that more people accidentally work on the same task?

Best,
Moritz

[0] http://git.github.io/SoC-2015-Microprojects.html

Re: Starting on a microproject for GSoC

[Stefan Beller]

On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@moritzneeb.de> wrote:
> Hi git developers,
>
> the next Google Summer of Code is not too far away. I expect git to
> apply for it and hopefully have some student spots which in turn I plan
> to apply. It was recommended elsewhere and on this list as well, that it
> is beneficial to engage with the community early, that's why I am
> writing to you already now, before all this formal stuff has begun.
>
> Before I may introduce myself: I'm a Computer Science student in
> Germany, coming towards the end of my Masters. I am an enthusiastic git
> user that's why I'd like to give something back.

Giving back is a noble thing. To have most fun at it, you need to ask yourself:
What is the most obnoxious part of Git that you personally use? What was
the latest problem you had, which you'd want to fix? If you identified
that, is that the right size to fix it? (Usually it is way bigger than thought,
but you can ask around if there are approaches for solving that problem ;)

> This would be my first
> time to actually contribute to a FOSS project and I am quite excited
> (also a bit frightened ;)).

Each FLOSS project is run differently. So in case your fright
was the right instinct, go for some other project, it will be totally different.

>
> As the list of available microprojects 2016 is still to be created, I
> might need your help in finding a project to work on. I started to dig
> through the archives along items of the list of 2015 [0] and so far
> found out the following:

Some smaller starter projects may be found at
http://git-blame.blogspot.com/p/leftover-bits.html
The size and difficulty of these projects may vary
a bit more than the micro projects for GSoC though.

>
> The first task, to make "git -C '' cmd" not to barf seems to be solved.
> I tried it with "git -C '' status" at least. I could not find the
> related patch, maybe it did use other keywords. I would be interested.
>
> The second task, to allow "-" as a short-hand for "@{-1}" in more places
> seems to be still open for reset, although someone almost finished it
> (cf. $gmane/265417). I suppose just fixing/revising this would be kind
> of a too low hanging fruit? More interesting (also because I am a bit
> earlier) might be to unify everything, as suggested by Junio in
> $gmane/265260. Or implementing it for another branch command, e.g. rebase.
>
> The other tasks I did not yet dig into.
>
> If all of that is considered as not relevant, I might just go for a
> newer idea, like converting strbuf_getline_lf() callers to
> strbuf_getline(), as suggested in $gmane/284104.
>
> Any thoughts?
>
> A question regarding the process of "taking a task (or bug)" in general:
> Is it solely organized through the mailing list?

Yes, I'd say 95% of the discussion is done on the mailing list.
(The remaining 5% is done on conferences,
or privately for security related stuff I'd assume)

> Suppose I start to work
> on something, should I announce it to not risk work duplication?

[In the context of fighting procrastination,] I recently read that announcing
that you are going to work on $FOO is not necessarily helpful
for actually doing it. Chances are lower that you actually finish a
thing which you announced.

However feel free to announce what you work on. Usually people don't.

> Does it
> happen often that more people accidentally work on the same task?

It happens rarely for larger goals. For the GSoc micro projects however
some students did the same thing with slight differences. (2015 we only
had 2 spots to fill but a few more applicants (3-5?), but seeing
how students approached the same problem helped on deciding whom
to mentor. (Given different problems it would have been harder.)

>
> Best,
> Moritz
>
> [0] http://git.github.io/SoC-2015-Microprojects.html

I just realized there are some micro projects on the 2014 page
as well which haven't been solved yet. (maybe, they are not
striked through)

Thanks,
Stefan

Re: Starting on a microproject for GSoC

[Moritz Neeb]

On 01/28/2016 02:18 AM, Stefan Beller wrote:
> On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@moritzneeb.de> wrote:
>> Before I may introduce myself: I'm a Computer Science student in
>> Germany, coming towards the end of my Masters. I am an enthusiastic git
>> user that's why I'd like to give something back.
> 
> Giving back is a noble thing. To have most fun at it, you need to ask yourself:
> What is the most obnoxious part of Git that you personally use? What was
> the latest problem you had, which you'd want to fix? If you identified
> that, is that the right size to fix it? (Usually it is way bigger than thought,
> but you can ask around if there are approaches for solving that problem ;)

You're right, creating something that is in the end relevant and useful
for myself is even more fun. I have some itches, I will work on
specifying them. I have the feeling though, that for solving the daily
issues and itches it's not necessary to dig into the core of git.

For example, I sometimes create a commit with the wrong email address (I
try to separate between work/private stuff) and that annoys me. I think
this could be solved by some hook rather than modifying git itself.

> I just realized there are some micro projects on the 2014 page
> as well which haven't been solved yet. (maybe, they are not
> striked through)

Yeah, I realized too that there are some points not striked through in
[0]. Might be just not up to date, for example number 15. seems to be
solved ($gmane//244020). Looking into the code, 14. is solved as well.
For 17. there could be something left.

Thanks,
Moritz

[0] http://git.github.io/SoC-2014-Microprojects.html

Re: Starting on a microproject for GSoC

[Andrew Ardill]

On 28 January 2016 at 11:40, Moritz Neeb <lists@moritzneeb.de> wrote:
> I suppose just fixing/revising this would be kind
> of a too low hanging fruit?

I am in no way qualified to speak to the majority of your post, but I
can't imagine anyone refusing your work because it was 'too low
hanging fruit'.

Indeed, the general gist of getting people to start with a
microproject has always appeared to help potential applicants
understand what it takes to get a patch accepted in git. As long as
the low hanging fruit is useful (your example of polishing a patchset
to get it into master is definitely useful, assuming the patchset is
useful) then I'd say go for it.

In the worst case, if you feel your contribution was not 'meaty'
enough, there is nothing to stop you working on some other problem, or
extending the first further. That said, I do remember previous
applicants trying to do as many microprojects as possible, leaving few
for other people.

Regards,

Andrew Ardill

Re: Starting on a microproject for GSoC

[Johannes Schindelin]

Hi Moritz & Andrew,

On Thu, 28 Jan 2016, Andrew Ardill wrote:

> On 28 January 2016 at 11:40, Moritz Neeb <lists@moritzneeb.de> wrote:
> > I suppose just fixing/revising this would be kind
> > of a too low hanging fruit?
> 
> I am in no way qualified to speak to the majority of your post, but I
> can't imagine anyone refusing your work because it was 'too low
> hanging fruit'.

I would agree that it is *not* a "too low hanging fruit".

The thing is, it would be a really easy way to get into the groove, to
understand how changes are expected to be contributed, what the process of
iterating the patches/patch series is, and in what form the patches are
preferred.

Moritz, if you worry about this lil' project to be too little, why don't
you just start with it and then tackle another one? That way, you will be
already very familiar with the Git project (and the regulars will be
familiar with you) when GSoC comes around.

Ciao,
Johannes

Re: Starting on a microproject for GSoC

[Lars Schneider]

On 28 Jan 2016, at 01:40, Moritz Neeb <lists@moritzneeb.de> wrote:

> As the list of available microprojects 2016 is still to be created, I
> might need your help in finding a project to work on.

As Stefan already pointed out, working on something that scratches your (Git) itch is probably the best way to find a project.
My recent itch was that I broke a test on Linux which I did not realize as I primarily work on OSX. As a solution for myself I suggested a TravisCI patch to the mailing list and it was accepted:
https://travis-ci.org/git/git/branches 

I see a number of ways to improve the Git TravisCI integration:

* install CVS on the build machines to run t94?? and t96?? tests
* install SVN on the build machines to run t91?? tests
* install Apache Web Server to run 5539, 5550, and 5561
* investigate if it is possible to run t1509 root worktree test
* investigate if it is possible to add jgit to run t5310
* investigate why GIT_TEST_LONG=YesPlease does not work on TravisCI
* investigate if we can use pylint to analyze the git-p4 Python code
* investigate if we can trigger Coverity static code analysis for the Git master
  branch (hint: Stefan Beller already looked into this)
  https://scan.coverity.com/travis_ci

I think all of these tasks can be done without deep Git knowledge. However, working with the tests is quite a good way to learn more about a complex project like Git.

Cheers,
Lars

Re: Starting on a microproject for GSoC

[Junio C Hamano]

Moritz Neeb <lists@moritzneeb.de> writes:

> the next Google Summer of Code is not too far away. I expect git to
> apply for it and hopefully have some student spots which in turn I plan
> to apply. It was recommended elsewhere and on this list as well, that it
> is beneficial to engage with the community early, that's why I am
> writing to you already now, before all this formal stuff has begun.

It is unknown if we are going to participate in GSoC this year.  One
question you must ask yourself first: will you still be interested
in hacking Git if we decide not to take GSoC students this year?

The GSoC microprojects are not about seeing who writes great code.
What we want to see primarily with them is how well candidates
interact with the community, responding to reviewers, showing
agreement or disagreement with received comments, making arguments
in a constructive way when opinions differ, updating their
submissions with suggested improvements in a timely matter to keep
the ball rolling, etc.  GSoC micros are primarily designed to be
small and can be finished within a short timeframe, but expected to
still have enough iterations with reviewers that candidates can use
as an opportunity to demonstrate how well they can work with the
community.

Suppose a candidate already tackled a micro, went through multiple
iterations with reviewers and came up with a polished solution.
When another candidate comes late and sends in a very similar
"answer" to the same micro, without meaningful interactions with the
reviewers and the community, the latter candidate would not be
demonstrating how good a "fit" s/he is in the community at all.

On the other hand, if the latter candidate approaches the same micro
somebody else attacked in a different way, s/he would have his or
her own interactions with the reviewers and would be demonstrating
his or her ability to work with us.

So in that sense, they are not "quiz" that has a single right
answer, and we do not necessarily have problems if multiple
candidates attack the same micro.

Now, if your answer to the "first" question is "No", then you might
want to avoid wasting your effort investing too early in preparing
for an event that may not happen.  You may want to stop reading here
and wait until GSoC micros are posted (if we decide to participate
this year, that is).

If the answer is "Yes", then welcome to the Git development
community ;-)

The purpose of GSoC micro I explained above also means that people
like you, who are interested in hacking Git, can start early and do
their own things to demonstrate that they can work well with our
community, which may give them a head start.  When they apply to be
a GSoC student (if we participate this year), we would already have
enough datapoint to convince ourselves that it would be a good idea
to pick them (even without them doing GSoC micro).

> The second task, to allow "-" as a short-hand for "@{-1}" in more
> places seems to be still open for reset, although someone almost
> finished it (cf. $gmane/265417). I suppose just fixing/revising
> this would be kind of a too low hanging fruit?  More interesting
> (also because I am a bit earlier) might be to unify everything, as
> suggested by Junio in $gmane/265260. Or implementing it for
> another branch command, e.g. rebase.

This actually is a very tricky one to do well.

> If all of that is considered as not relevant, I might just go for
> a newer idea, like converting strbuf_getline_lf() callers to
> strbuf_getline(), as suggested in $gmane/284104.

It is a good sign that you are familiar with a recent list
discussion.  There are other "once this topic settles, we would
probably want to do this and that kind of cleanups on top" left
behind that haven't made my "leftover bits" page (which I update
only after the discussion dies on the list and there is no sign that
others will be picking them up soonish).

Have fun.