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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
