On 02/26/2014 11:23 AM, Jeff King wrote:
> On Tue, Feb 25, 2014 at 06:15:28PM +0100, Michael Haggerty wrote:
>> Requiring students to submit a reasonable patch and follow up on review
>> comments seems like it would be a good way to filter out non-serious
>> students.  (I hesitate to require that the patch be accepted because it
>> can take quite a while for a patch to make it to master, despite of the
>> student's efforts.)
> Yeah, I think the early stages of "accepted" are somewhat vague.
> Probably "patch is in next" is a reasonable definition, but I do not
> think we even need to bind ourselves so strictly. Humans read, evaluate,
> and rank the proposals, so we can use our judgement about whether a
> patch looks promising.


> [...]
>> If we wanted to impose such a hurdle, then we would definitely have to
>> make up a list of microprojects so that the students don't have to start
>> from nothing.  [...]
>> If the reaction is positive to this idea then I volunteer to spend
>> several hours tomorrow looking for microprojects, and I suggest other
>> core developers do so as well.  They should presumably be submitted as
>> patches to the ideas repository [1].
> Yes, though I think it makes sense to put them on a separate page. We
> should probably write up some notes for students, too: how to get in
> touch with us, what do we expect of them in the pre-proposal period,
> what would we expect in terms of communication and day-to-day workflow
> during the summer, etc.

Since time is short, I already started on this.  I wrote a first draft
of an introduction for the students.  I also started looking for
microprojects.  I started going through our source files alphabetically,
and have already found six suggestions by "bundle.c", so I don't think
there will be a problem finding enough tiny things to do.

See my branch on GitHub [1] or read the appended text below.

I've been looking for *really* tiny projects.  Feedback is welcome about
whether they are too trivial to be meaningful in distinguishing
promising students from no-hopers.  My feeling is that there is so much
process involved in submitting a patch that it will take even a
well-prepared student quite a while to make a change, no matter how trivial.

Also, how many suggested microprojects do you think we need (i.e., when
can I stop :-) )?


[1] https://github.com/mhagger/git.github.io/tree/microprojects

layout: default
title: SoC 2014 Applicant Microprojects

## Introduction

It is strongly recommended that students who want to apply to the Git
project for the Summer of Code 2014 should submit a small code-related
patch to the Git project as part of their application.  Think of these
microprojects as the "Hello, world" of getting involved with the Git
project; the coding aspect of the change can be almost trivial, but to
make the change the student has to become familiar with many of the
practical aspects of working on the Git project:

* Downloading the source code: clone the repository using the
  [Git via Git](http://git-scm.com/downloads) instructions and read
  the `README` file.

* Build the source code: this is described in the file `INSTALL`.

* Glance over our coding guidelines in the file
  `Documentation/CodingGuidelines`.  We take things like proper code
  formatting very seriously.

* Read about the process for submitting patches to Git: this is
  described in `Documentation/SubmittingPatches`.

* Making the actual change.

* Run the test suite: this is described in the file `t/README`.  (If
  you have added new functionality, you should also add tests, but
  most microprojects will not add new functionality.)

* Commit your change.  Surprise: we use Git for that, so you will need
  to gain at least
  [a basic familiarity](http://git-scm.com/documentation) with using
  Git.  Make sure to write a good commit message that explains the
  reason for the change and any ramifications.  Remember to add a
  Signed-off-by line (see the coding guidelines for more information).

* Submit your change to the Git mailing list.  For this step you
  probably want to use the commands `git format-patch` and `git

* Expect feedback, criticism, suggestions, etc. from the mailing list.

  *Respond to it!* and follow up with improved versions of your
  change.  Even for a trivial patch you shouldn't be surprised if it
  takes two or more iterations before your patch is accepted.  *This
  is the best part of the Git community; it is your chance to get
  personalized instruction from very experienced peers!*

The coding part of the microproject should be very small (say, 10-30
minutes).  We don't require that your patch be accepted into master by
the time of your formal application; we mostly want to see that you
have a basic level of competence and especially the ability to
interact with the other Git developers.

When you submit your patch, please mention that you plan to apply for
the GSoC.  This will ensure that we take special care not to overlook
your application among the large pile of others.

## Ideas for microprojects

The following are just ideas.  Any small code-related change would be
suitable.  Just remember to keep the change small!  It is much better
to finish a small but complete patch than to try something too
ambitious and not get it done.

1.  Rewrite `git-compat-util.h:skip_prefix()` as a loop, so that it
    doesn't have to scan through the `prefix` string twice.

2.  Change `branch.c:install_branch_config()` to use `skip_prefix()`.

3.  In `branch.c:setup_tracking()`, figure out where the magic number
    `1024 - 7 - 7 - 1` comes from.  (Looking through the commit
    history might help.)  If the check involving the number is still
    necessary, document where the number comes from.  If the check is
    no longer necessary, explain why and delete the check.

4.  Rewrite `bulk-checkin.c:finish_bulk_checkin()` to use a `strbuf`
    for handling `packname`, and explain why this is useful.  Also
    check if the first argument of
    `pack-write.c:finish_tmp_packfile()` can be made const.

5.  Change `bundle.c:add_to_ref_list()` to use `hashcpy()`.  See if
    you can find other places where `hashcpy()` should be used instead
    of `memcpy()`.

6.  Change `bundle.c:add_to_ref_list()` to use `ALLOC_GROW()`.

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

Reply via email to