Starting on a microproject for GSoC

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

On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@moritzneeb.de> wrote:

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 ;)

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.

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.

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)

[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.

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.)

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

On 01/28/2016 02:18 AM, Stefan Beller wrote:

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.

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

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

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

Hi Moritz & Andrew,

On Thu, 28 Jan 2016, Andrew Ardill wrote:

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

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

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

Moritz Neeb <lists@moritzneeb.de> writes:

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).

This actually is a very tricky one to do well.

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.