[Fwd: Re: 3.0.25 svn rev. 21433]

[Thomas Bork]

Jelmer Vernooij wrote:

>>> If we'd import samba-vscan, that would mean that we'd have to make sure
>>> it keeps building and working during API changes, and also that we'd
>>> have to make sure the vscan side of it keeps working.
>> The vscan side *is* working today. The problem is the API change in 3.0.25.
> Yes, and my point is about the fact that we would have to make sure it
> keeps working, even during vscan API changes or fixing existing
> samba-vscan bugs.

*That* is the clue and thats why (the samba team had to keep the API or 
to fix the module) I like the idea so much :)

> Another option would be to create a new project around samba-vscan and
> have the community  help getting the samba-vscan module up to date
> before each release. That's what we did with samba-pdbsql, and that has
> worked out quite well.

If the community would be able to fix the problems with the API or if 
the maintainer had enough time, there were no problems at all at this time.
But that is not the case.
And if I would be able to do this, I would do this.
But that is not the case.

Maybe this is an argument:

I try my best to test new samba versions (also pre versions) as soon as 
possible on a wider base. The wider base is the community of 
eisfair.org. My samba package for eisfair makes use of samba-vscan. If 
samba-vscan is not available (because not compilable) for newer samba 
versions, it is difficult for me to find enough users to test the new 
samba versions in eisfair packages...


der tom