Practical Project Maintenance Thomas Vander Stichele GUADEC Birmingham 2007-07-19

Version 0.1

It's about Free Software

patches accepted

Why

Because it's your code

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

Goal

Goal

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

How

reorganize development one reorganize development to increase quality with minimal friction

two grow community of people

three make that community respect the process

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

four by doing releases that will work for end users

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

Reorganize focus on quality

Measure

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

Testing Interactive tests more “expensive” to run integration tests

Testing data validation tests fuzzing tests get error paths tested

Warnings

compiler warnings depecration guards documentation checks

broken windows

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

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

Bugs

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

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

Organize code

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

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

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

Dependencies

Dependencies how new is now ? consider distro release cycles

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

Version numbers

3 3.1 3.14 3.141 3.1415 3.14159 3.141592

TeX 3 3.1 3.14 3.141 3.1415 3.14159 3.141592

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.

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

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

Release

give the quality to the users with minimal bugs

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

How to release announce freeze stabilize prerelease test the ice

you announce a freeze mails come in

NO

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

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

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