Dave Shield wrote: > 1) OpenBSD4 headers > What would be the implications of adding > #include <openbsd3.h> > to openbsd4.h?
Huh? We neither have openbsd3.h nor openbsd4.h, but just openbsd.h. I think we should come to a consensus whether foobar42 means "foobar, version 42" or "foobar, version 42 or above". We currently use it either way, I think. Shall we introduce a new notion, e.g. "foobar42ff" (or somesuch) for indicating "42 or later"? (Not discussing the fact that most uses of "#ifdef foobar42" should actually be replaced by "#ifdef HAVE_QWERTY". :-)) > 2) if-mib rewrite > I believe Robert has already said that he plans a suitable mechanism > to enable this simply. Failing that, we could document setting the > CC > env var, but that does feel like a hack. Hopefully the former. > 3) hrStorageIndexes > I'm happy with the current state (unsurprisingly!), though > it's probably > sensible to document the change. Any objections? Do you care to summarize the changes? > 4) DisMan event crash > I'll look at this as soon as I get a free minute > (And remember to bring my laptop power cable home with me :-() Thanks. > 5) 64bit nlist > This feels a bit too large a change to consider this late in > the release. > But I admit that I haven't checked the impact of the relevant bugs. > Does anyone want to volunteer to tackle this, or shall we > postpone till 5.4.1? I'm currently working on it and hope to finish it up before rc1. > 6) SIGHUP errors > This strikes me as "nice, but not vital". > If I get the time, I'll try to have a look at some of these, > but it doesn't feel worth delaying 5.4 for. Would be nice, indeed. > 7) perl compiler warnings > If they're simply warnings (rather than errors), then leave till > 5.4.1 > Unless they actually indicate a more serious problem? Compiler warnings often point to serious programming errors. Classifying them as harmless or serious is only possible *after* investigation, so this keeps being a grey area for now. > 8) "as-needed" linking > Again, I haven't checked the relevant bugs, but this feels as > if it might > be a more significant issue than many of the others. > How damaging would it be to ship things as they currently stand? OSX is the only one that fails during "make". On the other (older) systems problems probably only happen when doing "make install DESTDIR=/some/where/else". > 9) OS X embedded perl > If it's just embedded perl that's broken, then leave till 5.4.1 Add a note to README.osX? Shall we hold off enabling embedded perl by default on OSX? Any other OSX users willing to build, run "make test" and report back? > 10) configure sed failures > See earlier proposal to drop AC_SUBST( *module_list_h ) > as a temporary workaround. ACK, although I'm still looking for a better fix. > R1) TCP notifications > This seems to be the biggy - at least it's the only entry > categorised red. > Do we agree that it needs to be fixed before release, or should it be > re-graded yellow. If it stays red, who understands the problem/code? I think it should get sorted out for 5.4 before we're tied to backward compat problems. +Thomas -- Thomas Anders (thomas.anders at blue-cable.de) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
