Skip to content
Changing the X server development process – Keith Packard
- Old Old model – Everybody commits to master, at some point only do “necessary patches” , release manger
- cuts release at some point – didn’t scales to lots of devs
- Old model – everybody to master – release branch made – additions by editing wiki page adding ids –
- release manger cherry picks
- lack of testing of release branch, a bit of overhead, 4-5 releases
- Idea to copy Linux kernel
- New Model –
- only one person commits to master
- Some people publish own trees
- Some people send patches to xorg-devel, easy entry
- All patches need to be reviewed before being merged
- Not quite the Linux model – only general agreement needed to merge – release management more
- mechanical, just checking patches have review, merge cleanly, testing after each patch
- Why Change?
- bad at hitting scheduled dates
- git master frequently unstable, sometimes not even build-able
- little discussion about even major changes
- limited release testing, largely caused by instability of master
- 6 month release period, aligned with fedora, ubuntu, meego
- last 2 releases 4 days slip and 0 day slip
- Context 1-5 – 1.7 very active dev period, 100,000s LOC removed
- all commits are supposed to be reviewed
- not to worried if reviewer comes from same company as long as they are credible and know that area.
- contributors 50-100 per release, dropping a bit in 1.8 and 1.9
- Big jump is patch related threads and other threads on mailing lists?
- Success?
- dramatic reduction in LOC changes
- Dramatic increases in communication
- Hitting releases on time
- Meet original objectives
- lack of useful test suite
- testing to just make sure basic build
