Re: [gamin] gam-poll.c rewrite

[Daniel Veillard <veillard redhat com>]

On Fri, Jul 01, 2005 at 04:46:21PM +0100, Neal H. Walfield wrote:
> > This really can have a large impact and it's very hard to assess
> > how many things will break. Things do break on changes, no matter if
> > this is right or wrong to do the change, and gamin potentially affects
> > a lot of desktop applications and expected user behaviour. Adding monitors
> > to the full hierarchy is taking a lot of risks IMHO.
> 
> It sounds to me like there is something more you wan to say here.
> Otherwise it seems to me anything that self-describes as a rewrite is
> high risk.

  yes rewrite is high risk, I said that already. I'm balanced between the
fact we are at 0.1.x and code need to be cleaned up and improved, and you're
a big part of it, and on the other hand I have deployed code and lot of 
software depending on the behaviour of the library, which is way more complex
than the API description.

> >   My view about this is "Open Source is a process", that process means to
> > operate as a team, in an open fashion, and pushing big changes like the
> > recursive monitoring should never be done silently. If you do so, you break
> > the knowledge of every other people in that team, reducing the value of the
> > code in the end, even if intrinsically the code may be better after that.
> 
> I tried to summarize the changes this patch introduces in the mail
> accompanying the patch.  Of course, it is only summary and I
> encourage you to study the patch.

  paphio:~/gamin -> wc gam-poll.diff
   3075 12082 95508 gam-poll.diff

there is only so much scrutinity I can apply this, is huge by all standards.

> > > The debugging API exposes implementation details.  If the
> > 
> >   Those implementation details are crucially important. If I get a Changed
> > even because I watched using dnotify versus because watching with poll it
> > is very different, this may meen the busy detection code in the server just
> > failed. I also want to monitor that there is no leak of kernel monitors
> > from the regression tests because that means leaks of filedescriptors and
> > potentially filling hard drives with unreachables but still open files.
> 
> 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.

> documentation:

  No this has nothing in common, if those tests fails this usually mean
some application will fail when reproducing those conditions, documentation
has no such property.

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/