Dave Jones davej at redhat.com
Fri Sep 3 09:47:40 PDT 2004

On Fri, Sep 03, 2004 at 10:40:25AM -0600, Ray Lehtiniemi wrote:
 > On Fri, Sep 03, 2004 at 05:01:56PM +0100, Dave Jones wrote:
 > > 
 > > I've spent the last few days playing around with sparse & xorg.
 > > A sort-of compiler written by Linus Torvalds, (snapshots here:
 > >  http://www.codemonkey.org.uk/projects/bitkeeper/sparse/)
 > > which outputs lots of warnings about things, but no actual code.
 > are these just snapshots of http://sparse.bkbits.net/, or snapshots
 > with your local changes as well?

Just of Linus' tree.  I can make snapshots of my changes too if
theres any interest in doing that.

 > > There's tons of low-hanging fruit for anyone motivated here.
 > > >From experience with the kernel janitor project, I'd suggest just diving
 > > in to some random file, fixing stuff up and posting/filing bugzilla
 > > reports as you go along rather than trying to do a single sweep-n-clear
 > > operation in one go, which usually results in a half dozen people doing
 > > the same thing.
 > just checked out http://janitor.kernelnewbies.org/, very nice!  
 > looking at the latest patchset, is seems that a lot of it is
 > sweep-n-clear type of changes (min-max, list_for_each, remove-old-ifdefs)
 > how are those coordinated?

How things work out for the kernel is that occasionally Andrew Morton
scoops up the latest pending stuff from the janitor folks, and includes
it in his 2.6-mm tree for a while to get some extra testing before
pushing it on to Linus.   Sometimes the janitor bits get dropped in
favour of something more important (ie, something fixing a real bug)
which causes another round-trip after the janitor folks resync..

 > once a certain class of errors has been tackled and minimized, do you
 > guys make any attempt to prevent new errors of that type from creeping
 > in? or is that even feasible to do?

It's a nice idea in theory, however with the volume of patches going
by, occasionally stuff does get missed.  For that reason, the 'TODO'
list is more a crib list of possible things to look out for than
a list of things that need tackling, which then get removed.


More information about the xorg mailing list