Re: [gamin] gam-poll.c rewrite

["Neal H. Walfield" <neal walfield org>]

> > I'm rather confused.  It makes sense that the implementation is sound
> > and that we should somehow check that.  I don't see why exposing the
> > implementation details are crucially important.  It seems like
> 
>   I stated why ! It's crutially important to be sure that:
>     - busy inode detection work and disabling reenabling of kernel monitoring
>       on flood, it's crucial to do this in automated tests because doing this
>       by hand on a real desktop app is incredibly tedious and error prone.
>     - monitoring the kernel watches is crucial because it's monitoring the
>       system resources to implement the API including in hard to reproduce
>       cases
> 
>  those automated tests are why I can trust code for a release.
> Basically I can't make a release until those are broken, and I won't. As a 
> result I won't commit until we get back to a state where I can assess 
> dnotify/kernel monitoring from the regression tests.

Just to be clear, you want the failed debug tests analyzed and fixed
for the new code?