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 [off-list ref] 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
On 28 January 2016 at 11:40, Moritz Neeb [off-list ref] 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
Hi Moritz & Andrew,
On Thu, 28 Jan 2016, Andrew Ardill wrote:
On 28 January 2016 at 11:40, Moritz Neeb [off-list ref] wrote:
quoted
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
On 28 Jan 2016, at 01:40, Moritz Neeb [off-list ref] 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
On 01/28/2016 02:18 AM, Stefan Beller wrote:
On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb [off-list ref] wrote:
quoted
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