On Tue, 2005-10-04 at 07:02 -0700, Wes Hardaker wrote:
> >>>>> On Sun, 2 Oct 2005 09:55:46 +0100, Dave Shield <[EMAIL PROTECTED]> said:
>
> Dave> But surely what we're interested in providing (by default) is the
> Dave> Event-MIB *functionality*, rather than a particular implementation?
>
> I think Robert's point should be if we're turning it on by default
> it should be somewhat well tested code.
Traditionally, our main concern over enabling modules by default
has been that the code should at least *compile* reliably, so that
the agent could be built on all architectures.
I'm convinced that this new implementation should compile cleanly
pretty much 100% of the time - there's nothing architecure-specific
in it, so it shouldn't trigger any unexpected problems. (Or at
least, no more than the previous implementation would).
Obviously, the new code won't have had the same exposure to practical
use - has anyone else here actually tried it out yet? So I can't
sensibly make the same comments regarding its use. But I'm reasonably
confident that this implementation ought to work at least as well as
the previous code. And the new structure is (IMO) both clearer and
cleaner, so it should be easier to debug.
> The only question
> left becomes: how sure are we that it works at least as good as or
> better than the current version such that all the people that are
> using the current version in production environments will feel secure
> that we've done this without a huge amount of testing?
How sure am I?
Now: about 50% (given that I *know* I haven't tested threshold
tests or discontinuities in delta-samples yet.
Plus I've still to complete the delta-threshold
code, add the missing config directives, and
implement the scalar objects)
By next week:
probably about 80%
(particularly if someone can suggest a suitable
wildcarded discontinuity OID than I can try)
Post 5.3.preN:
about 95% (since hopefully other people will actually have
*tried* this code as part of that process, rather
than just bemoaning the very idea of change!)
> >> Might I suggest a configure flag (--enable-disman-rewrite) for 5.3,
> >> with the switch to the new version as the default in 5.4?
>
> Dave> What's the point of that?
>
> I think the point would be to give developers one more release cycle
> to test it.
I made that mistake with the mibJJ code. Nobody could be bothered.
If it's not in by default, then most people won't bother trying it.
If it's an optional replacement for something that *is* there by
default, then even fewer will bother.
You've always said that I needed to push my offerings more, Wes.
Well, now I'm pushing!
> I think we should have some more flags configured on by default for
> cvs checkouts... This would be an example of one.... IE, if you're
> checking out CVS you get the newest code by default.
I intend to do that as soon as the code is "complete" - hopefully by
the end of this week. I'm also inclined to enable the schedule MIB
implementation.
You did spot that I'd implemented that as well, didn't you?
And I've already started casting my eye over the expression MIB code :-)
> I think on the whole, I'm inclined to agree with Dave and say it could
> go into 5.3 as long as:
>
> 1) he finishes it
I'm working as fast as I can.... :-)
> 2) he really really does believe it'll be less prone to
> bugs/errors than the current code.
I do - see above.
(And remember who's supplying the figures above - 50% or 80%
may sound pretty low, but you need to factor in Shield caution!)
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
