> > 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? _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
