Dave> I don't think it's fair to add this sort of new functionality,
Dave> and then *immediately* go into pre-release mode.
Wes> Which means your belief is that feature freeze should actually begin
Wes> before the first pre-release
No.
It means that I believe that the idea of a feature freeze isn't necessarily
a black-and-white, on-or-off, clear cut thing. Introducing a relatively
minor new feature that can simply be ignored if desired, is one thing -
adding that at the last minute is no big deal. Significantly changing
the way that a major part of the system works isn't quite the same.
Wes> you've implemented huge
Wes> new MIBs all in the last week or so... yes, you beat the last
Wes> second deadline by a week or two but with a huge amount of code).
Some new code, yes - I get fed up with writing documentation, as
well :-) But take a look at what those contributions include:
- a new version of the Event MIB
(same basic functionality as before, just
different internals & extended slightly)
- reworking of the Schedule MIB
(the basic code has been present for some time,
the main change is to include it by default)
- a fuller implementation of the Expression MIB
That last is really the only new *feature* - but it's very much a
work-in-progress, and has to be explicitly configured in. The only
significant new core feature is my work on the generic table API.
And you can hardly accuse me of slipping that in at the last minute.
I've been begging people to comment on it for weeks!
Wes> We certainly could apply easier to use tokens in the future for
Wes> all the VACM stuff. I think we're too late to talk about that
And that's exactly what I'm objecting to!
You seem to be saying:
Thursday> Here's this whizzy new (mandatory) feature...
Friday> ... but there's no time to talk about it.
Totally out of the blue - no warning or anything. I even checked
the IRC logs, and there didn't seem to be much detail discussed
there - let alone anything on the coders list. At the very least,
we should have a couple of days to look at your new code, think
about it, and suggest possible adjustments.
Fundamentally, you're the founder of this project, and can take it
in whatever direction you like. I'm not going to throw a paddy
if you insist on things gong ahead as they stand. But I have to
say that I don't think this is a particularly sensible stance.
I've got a number of more technical things to say, but they're
best left for another message.
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
