1. Practical Project Maintenance
Thomas Vander Stichele
GUADEC
Birmingham

2. Version 0.1

3. It's about Free Software

4. patches accepted

5. Why

6. Because it's your code

7. you like someone else's project and you want it to grow

8. Goal

9. Goal

12. Mediate fantastic new code excellent bug fixes rocking features
developers
experience
of user
installing
software

13. How

14. reorganize development
one
reorganize development
to increase quality
with minimal friction

15. two
grow
community
of people

16. three
make that community
respect the process

17. because they share the goal
three
because they share the goal
but they want to hack

18. four
by doing releases
that will work
for end users

19. by getting those releases
five
by getting those releases
onto computers
of users

20. Reorganize
focus on quality

21. Measure

22. Testing Unit tests run for every check-in with a buildbot- like tool
generate coverage data
valgrind unit tests
profile unit tests

23. Testing
Interactive tests
more “expensive” to run
integration tests

24. Testing
data validation tests
fuzzing tests
get error paths tested

25. Warnings

26. compiler warnings
depecration guards
documentation checks

27. broken windows

28. possibly harmless warnings obscure harmful ones
Are you smarter than the compiler ? Every time ?
zero tolerance is easier to maintain

29. Friction add warning checks after they pass
fix yourself or create the buy-in and get people to help

30. Bugs

31. fool you twice, shame on you
put your knowledge about the bug in a test

32. Stack hacking bug can be in any layer
higher layer bug exposing lower layer bug
fix top to bottom

33. Organize code

34. mental friction coding style change at stable points
mirror directory layouts
inline API docs

35. avoid copy/paste internal libraries good for testing too
share build infrastructure
One Two Many

39. do it the first time
copy it the second time
refactor and abstract after that

40. Dependencies

41. Dependencies
how new is now ?
consider distro release cycles

42. Dependencies how many people can use your code if it depends on
unreleased development code
the latest source release
packaged updates
packages in the last distro versions
packages in the previous distro versions

43. Version numbers

44. 3
3.1
3.14
3.141
3.1415

45. TeX 3
3.1
3.14
3.141
3.1415

46. TeX
... the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.

47. 0.93
1.0pre1, 2, 3
1.0pre3try2
1.0pre4, 5
1.0pre5try2
1.0pre6
1.0pre6a
1.0pre7, 8

48. MPlayer 0.93 1.0pre1, 2, 3 1.0pre3try2 1.0pre4, 5 1.0pre5try2 1.0pre6
1.0pre6a
1.0pre7, 8

50. Release

51. give the quality to the users
with minimal bugs

52. quality is a random walk
with possibly big discontinuities
releases should capture the local maxima

54. How to release announce freeze stabilize prerelease test the ice

55. you announce a freeze
mails come in

56. NO

57. my feature ? NO
my API addition ? NO
memleak fixes ? NO
non-regression bug fixes ? NO

58. my feature ? NO
my API addition ? NO
memleak fixes ? NO
non-regression bug fixes ? NO

60. Yes documentation fixes bug fixes for regressions crasher bugs
more tests
translations