I don't get your attitude and I don't like it.  I have volunteered to
help with this feature, stop the 'script to MIB' stuff, I know that
writing code to implement a MIB is an involved process and I am
willing to help where I can.  You seem to have a very 'holier than
thou' attitude about this whole thing and I do not get where that
comes from.  It is annoying and is dragging this thread off topic.

No one said you were going to have to be the one to implement this on
your own.  Dave asked for volunteers and I stepped up to volunteer.
When did you volunteer for this feature?  I saw no email to that
effect, all I see are complaints and attacks.  Where is that coming
from?

Your attitude is both hostile and aggressive.  What is up with that?
Are you interested in scaring everyone off from trying this?  If so,
why?  Who made you the lead on this feature and put pressure on you?
No one.

Dave said it would be on the TODO list, I said I would be willing to
help, Les initially asked about this .. then you chimed in with
attacks and complaints.  Is that the type of contribution you wish to
make to this potential new feature?


On 10/31/07, Bruce Shaw <[EMAIL PROTECTED]> wrote:
> BS>> You missed my point - which is what I get for being (sort-of)
> sarcastic.
>
> Max>I didn't, I said it was a huge undertaking and it is, no doubt.
>
> Max>I also think it is a worthwhile one, it may be a long term effort to
> Max>have Net-SNMP support this internally, but long term would be an
> Max>excellent feature.
>
> We have limited development resources.  There are many things that would
> be "excellent features" that we simply don't have the resources to
> develop.
>
> Max>Yes, it probably IS impossible to support every platform and every
> Max>driver, but even adding support for the most common NICs on the most
> Max>common Linux,  BSD, and recent Solaris (9 or 10+) would be huge, no?
> Max>Maybe the answer really is no for you.  Fine.
>
> Is anybody else stepping up to the plate?
>
> Max>As far as the script to MIB comment, again, I said if you have
> control
> Max>over the environment you are managing, I in no way posited that as a
> Max>long term solution to this issue, which is why I said HACK.
>
> I don't know about you, but I work with production boxes with limited
> resources.  I have to justify every machine cycle I use.  Again, it is
> not "script to MIB", there's hardware, an operating system and umpteen
> users in the way.
>
> BS> your platform here), I could probably have something cobbled
> together
> BS> for first alpha in about a year ([sarcasm]unless, of course, my
> employer
> BS> actually wants me to do some work for a change [/sarcasm]).
>
> Max>How about dropping the sarcasm and just focusing on what would be a
> Max>reasonable scope for a first crack at adding this as a feature?
> What
> Max>target platforms / setups would give you the most value, for
> instance?
>
> Lemme see, considering I've never done one of these from scratch, I'd
> need to learn how to populate a MIB (hopefully I could steal some code
> from somewhere), learn what portions of the MIB would routinely be
> populated as housekeeping (you can't just deliver the duplex setting,
> you have to say what interface you're delivering it for - the MIB will
> tell you what is mandatory), figure out how to do that for Solaris x86,
> Solaris SPARC, Solaris ULTRA, Solaris CoolThreads, do this for eri, hme,
> ce, e1000g drivers, using kstat, picld or whatever, test on the
> half-dozen or so platforms available for me, solicit testers for Solaris
> platforms I don't have (hmmm...that didn't go very well for sensors),
> somehow or other get access to a linux box, come up to speed in linux,
> do the preceding process for linux, solicit linux users.....
> Hmm....I'd say about year to first alpha.
>
> Max>Or is your project so general that you can't make a prioritized
> list?
>
> Well, you see, I work for a living.  My employer allows me a limited
> amount of time to work on Open Source projects because they have
> developed a need for Open Source because certain box-ware wasn't meeting
> their needs.  Said box-ware currently doesn't give me a way of quickly
> determining if I've got a duplex problem, hence I have a certain amount
> of interest, otherwise I wouldn't have spoken up in the first place.  Be
> that as it may, they pay me, you don't.  If they aren't getting value, I
> don't write code.
>
> Be that as it may, if people more knowledgeable than I are willing to
> work with me on the stuff I don't grok, and I contribute my specific
> expertise, maybe we can get something accomplished.
>
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have received this email in error please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail.
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to