Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> Since the purpose of a GSoC microproject is to familiarize the
> candidate with the project's mailing-list workflow and to give the
> GSoC mentors a feel for how the candidate interacts, perhaps the
> easiest suggestion would be the old fallback of having the candidate
> look for a single test script which still uses `test -f` or `test -e`
> or such, and converting that to use one of the test_path_foo()
> functions from t/test-lib-functions.sh.
During today's discussion, we came up another interesting one.
Follow one of our three tutorial documents to the letter to see
if they need adjusting, and come up with a set of patches to
adjust them.
This kills a few birds with a stone.
- The student has to be familiar with the codebase and MyFirst
tutorials are meant as a gentle "dip your toes in the water"
introduction. Following the examples and copy-pasting code
snippet and trying to build would be useful exercise for GSoC
candidates by itself.
- These tutorials, unfortunately, haven't been maintained as well
as they should have been, and some do not compile any longer due
to API changes, header shuffling, etc. Identifying such breakages
and reporting them as bugs is already useful by itself, even if
the student does not manage to fix them.
- But if the GSoC student can learn to address such a bug (which
requires use of "git log" and "git blame" to spelunk where the
breakage happened, after which it would be obvious what the right
fix would be), that is valuable exercise by itself, even if it
does not reach the "patch submission" stage.
- And of course, the result of such a work can go through the usual
patch review cycle, which would serve as a microproject.
Hmm?
