Re: [gamin] gam-poll.c rewrite

[Daniel Veillard <veillard redhat com>]

On Fri, Jul 01, 2005 at 06:14:24PM +0200, Neal H. Walfield wrote:
> > > 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?

  Ideally I would like the new code to only watch the parent directory
(and only when watching a directory resource), which then mean that the
new set of debug events is predictable, so we can fix the debug tests.
  So yes, but the watch is the crucial part, I can fix the tests based
on that premice.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/