|
yading@10
|
1 Google Summer of Code and similar project guidelines
|
|
yading@10
|
2
|
|
yading@10
|
3 Summer of Code is a project by Google in which students are paid to implement
|
|
yading@10
|
4 some nice new features for various participating open source projects ...
|
|
yading@10
|
5
|
|
yading@10
|
6 This text is a collection of things to take care of for the next soc as
|
|
yading@10
|
7 it's a little late for this year's soc (2006).
|
|
yading@10
|
8
|
|
yading@10
|
9 The Goal:
|
|
yading@10
|
10 Our goal in respect to soc is and must be of course exactly one thing and
|
|
yading@10
|
11 that is to improve FFmpeg, to reach this goal, code must
|
|
yading@10
|
12 * conform to the development policy and patch submission guidelines
|
|
yading@10
|
13 * must improve FFmpeg somehow (faster, smaller, "better",
|
|
yading@10
|
14 more codecs supported, fewer bugs, cleaner, ...)
|
|
yading@10
|
15
|
|
yading@10
|
16 for mentors and other developers to help students to reach that goal it is
|
|
yading@10
|
17 essential that changes to their codebase are publicly visible, clean and
|
|
yading@10
|
18 easy reviewable that again leads us to:
|
|
yading@10
|
19 * use of a revision control system like git
|
|
yading@10
|
20 * separation of cosmetic from non-cosmetic changes (this is almost entirely
|
|
yading@10
|
21 ignored by mentors and students in soc 2006 which might lead to a surprise
|
|
yading@10
|
22 when the code will be reviewed at the end before a possible inclusion in
|
|
yading@10
|
23 FFmpeg, individual changes were generally not reviewable due to cosmetics).
|
|
yading@10
|
24 * frequent commits, so that comments can be provided early
|
