On Wed, 2005-11-02 at 10:59 +0100, Thomas Anders wrote: > Dave Shield wrote:
> > By the criteria I proposed last year, this means that it > > doesn't fall into the category of "show stopper", and so > > the fix should wait until after the 5.2.2 release. > > I strongly disagree. > I still call the embedded perl support in snmpd and snmptrapd > "major, recommended functionality" The problem that we've *always* had with this project, is the (quite understandable) desire to fix "one last bug" before making a new release (and the consequent risk of screwing things up and releasing completely broken code). We found that we kept pushing the release data back, again and again and again, in order to squeeze in yet another fix. That's what led to the introduction of a "code freeze" - the point at which we say "this is as good as we can get for now, we're releasing this version as it stands, bugs and all". The point of the release candidate phase was to pick up on serious problems - "show stoppers" - before they actually got released. But the difficulty with that we found we were constantly debating whether a particular bug qualified as a show-stopper or not. That's why I came up with a concrete definition - something a little more objective than "a bug that's biting me personally" :-) This comprised two basic tests - these being: - does the default configuration compile successfully? - does "make test" run successfully. The rationale behind the first test was that if the "main" project code doesn't compile on a "supported system", then it's probably foolish to release things in this state. If a "fringe" part breaks (or there are problems on an obscure system) - oh dear, what a pity, how sad, never mind. But that still requires an objective way to distinguish between "main" and "fringe" elements - the obvious choice was the default configuration. If something is useful on a particular architecture, then it should be included. If it's not important enough to include by default, then it's not important enough to hold up the release. The rationale behind the second test was to ensure that the software "worked" - again using some *objective* definition of working. The obvious candidate was to run "make test", which is part of the instructions for preparing a release candidate. Once again, if something's is known to fail according to this objective measure, we should fix it before proceeding. If something's not important enough to have a "make test" check, then it's not important enough to hold up the release. If you can come up with some better *objective* definitions of a "show-stopper", then I'd love to hear them. > (e.g. with snmptrapd this is the *only* way > for scalable notification handling!) and hope for supporting > votes to have it working in 5.2.2. Please! I sympathise, but my vote is no. The 5.2.2 release is already slipping seriously, and needs to go out ASAP. > As for your arguments: > > 1) "not in default build": One major reason for it are the dependencies > (on Perl itself, our NetSNMP Perl modules and the compiler that has been > used to compile Perl) it introduces. Then craft "configure" tests to check whether perl, and the NetSNMP modules are available. > 2) "not part of make test": given that our test suite leaves something > to be desired (politely said), this is not a fair argument. Then write extra tests. I quite accept that the current "make test" is far from perfect. Part of the idea behind proposing this as part of the definition for a showstopper, was to provide an incentive for improving and extending the test suite. If you provide suitable tests for the bits that you're interested in, then you've got greater leverage for getting fixes into a new release at a later stage. If you can't be bothered, then you don't! :-) > Also, to emphasize, the embedded perl support (if turned on) currently > fails: > - completely (doesn't work at all, both for snmpd *and* snmptrapd) > - for everyone on any platform > - silently (no errors messages at all; it even says "initializing perl" > with -Dperl) Does the agent actually crash? (That's a third criterion that I'd probably suggest adding to the definition of a show stopper) Dave ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
