%include "default.mgp"
%default 1 bgrad 4 4 4 76 1 "black" "blue"
%%%%
%page
%nodefault
%center, size 7, font "standard", fore "white", vgap 20

Creating A Stable Kernel
%center, size 6, font "standard", fore "white", vgap 20

Alan Cox
%page

The Linus Torvalds 2.6 Model

Development
	Test changesets within -mm maybe
	Merge large change sets

Release Candidate
	Smaller changesets
	Essential fixes

Release Version
	Now what ??


%page

The Problem

We Know
	Large sets of changes cause bugs
	Most users don't test -rc or devel code
	Linus is a great developer
	Linus is a crap engineer

Releases
	Tend to have some commonly hit bugs
	Need updating for security fixes

But Linus isn't doing this

%page

Early Errors

Relatively Simple
	Mailing list reports
	Bugzilla data (including vendors)
	Few bugs, many reports
	Fixed rapidly (in devel tree)

Problems
	Not all fixes are right
	Some problems can be hard to fix

%page

Security Errors

Sources
	Bugzilla
	Vendor-sec
	Mailing list
	Private emails

Most are
	Trivial fixes
	Boundary cases
	Error paths

%page

Hard Security Errors

Conceptual/Design Errors
	eg 2.6 - 64bit long I/O
	Fix tends to be core code changes
	High risk fixes as a result
	Linus is happy to make big core changes
	Need alternative fixes

Trade Offs
	Small fixes may be more correct
	Linus cares for future
	Our hacks can be ugly (short term)
	Changes that alter user space behaviour

%page

Does An Error Matter

Many Errors
	Are root only
	Are harmless
	Cause little harm

Fixes
	Always add risk
	Make changesets larger

Try to avoid fixes to low harm bugs

%page

Longer Term

Over Time
	Core kernel diverges
	Fixes become harder to backport
	Bugs left are less serious
	Long term backporting is very hard

Therefore -ac
	Only supports the 'current' kernel
	Tries to remove changes when possible
	Pushes changes to Linus ASAP

Long term requires a team of engineers [RHEL/SLES etc]

%page

The -ac process

Changesets
	Takes each Linus changeset
	Drop cleanups
	Drop driver updates (except major fixes)
	Tag security changes (reported and silent)
	
Reports
	Identify most common reports
	Identify less common but serious problems 
		Corruption
		Silent failure
	Identify easy fixes

%page

The -ac process continued

Patch Building
	Take the most critical bug fixes
	Security fixes
	Try to defer fixes if changes overlap
	Try to spread fixes for debugging

Tools
	diff, patch
	evolution search for the changeset mailbox

%page

Goals

After Release
	Fix the early user reported bugs fast
	Queue high risk fixes

When it Quietens
	Group high risk fixes into test -ac's
	Avoid mixing security and risky fixes
	Ensure users have a stable option always

Longer Term
	Track fixes
	Push fixes to Linus if needed
	Try to avoid releases once basically sound
	(risk exceeds value)

%page

The Balance

Good of the many versus good of the few
	High risk patches for obscure users
	Obscure architectures
	"But I hit this bug"
	Fix one, break another (VM!)

%page

Conclusion

The 2.6 -ac tree tries to provide a conservative fix to Linus lack of 2.6.x.y trees. 

IMHO
	The right fix is still official 2.6.x.y trees
	Wants to have 3 or 4 maintainers reviewing
	Need a better security policy for semi-public bugs