On Wed, 3 Nov 2004 21:12:36 +0000 Dave wrote: DS> But I got the impression from the previous message that you DS> felt I was being excessively over-cautious, and it hit a nerve.
I wholly expect you to be over-cautious, as I'm sure you expect me to be over-eager (and perhaps over-bearing :-O ). I'm not trying to say that you are excessively cautions, I'm trying to say I think I've been cautious enough, and I'm tring to convice the group of that. I don't particularly expect to win you over, but I'll certainly keep trying. DS> No - there's certainly a case for including this fix in 5.2. DS> Personally I don't think it's significant enough, but I'm a Unix bigot, DS> so MinGW support isn't particularly high on my list of priorities. I quite understand, and if it hadn't been me who broke it in the first place, I might well be over on the other side of the fence with you! DS> But there were three things in particular that I didn't feel you DS> were paying sufficient attention to: DS> DS> - just 'cos two people have tried something and found it works, DS> is not sufficient to guarantee that it doesn't break something else. DS> It only takes one minor slip that isn't picked up to fuck things DS> up completely. DS> I've done it, Wes has done it, we don't want you to do it too. Oh, rest assured, I've done it too. DS> - changes to the configure environment are never "only". DS> It's the one piece of this overly-complex morass of code that is DS> the least well understood by any of us. Agreed. I do think, though, that I've got a fairly good grasp on it these days. I mucked about with it a bit, and even added comments and debugging to it in this release. DS> You may have "visually inspected" the configure.in patch. Do DS> you seriously expect me to believe that you've also checked the DS> configure script itself? That's the bit that *really* matters! The configure.in portion of the original patch was withdrawn. The only remaining part is an ifdef around a config_require in a header. DS> - some four hours after your message stating that things have been DS> thoroughly tested and found to work (pouring scorn on my concerns), DS> Alex asked if anyone had tested this under Cygwin. I've still to DS> see a positive response. "I suppose I should" doesn't count. Playing both sides of the fence, eh? Not worried that MinGW is broken, but concerned about Cygwin? :-P The patch removes a config_require if WIN32 is defined. I have verified that Cygwin does not define WIN32, and does include the module. So Cygwin is in the same boat as all the unix derivatives. If anything, cygwin may require an additional condition on the ifdef to exclude the code just like MinGW. In other words, the patch does not affect cygwin's current (unknown) status. DS> > The other factor is that we've been pretty flexible about these things DS> > in the past. DS> DS> And as I've tried to make clear, we've probably been *too* flexible in DS> the past. I thought we'd agreed to try and be a little more rigorous DS> about such things. And I think we have. We've gone from "I just checked this fix in" to "you need 3 core developers in agreement to check in showstopper fixes after a freeze." DS> The whole idea of a code freeze is that it actually DS> *freezes* things - accepting a loss of flexibility for a gain in stability. But it doesn't mean a complete loss of flexibility, or we might as well just ship when we freeze and fix bugs in the next release. DS> > I thought the whole idea of allowing voting was to recognize that DS> > there are occasional exceptions. DS> DS> Unless I misunderstood Wes completely, the idea of voting was suggested DS> for new features post-5.2 and before breaking off 5.3. It was not intended DS> to completely bypass the quality-control mechanisms that we have DS> (belatedly) put into place. Well, one of us misunderstood. I thought the voting *was* the quality control mechanism. If nothing can be changed, then we should just ship what we've got. DS> The thing that really annoyed me was the suggestion that a 5.3.pre3 DS> release wouldn't be necessary. If you do *anything* to the configure DS> script, then I definitely think we need another pre-release, to make DS> sure that we haven't broken some really obscure environment somewehere. First, configure hasn't changed. Second, I said *I* didn't think it was necessary, because I'm confident that this piddly little 2 line patch isn't going to break anything. DS> I don't for one minute believe you have, but I don't think we should DS> take the risk. So it comes down to one simple question - is this DS> fix worth pushing the whole release back a week, or not? The week delay was the reason I didn't want another pre-release. I almost suggested simply doing rc3 on Monday, since *nobody* had even downloaded rc2 from SF yet. DS> I think you're trying to have your cake and eat it.... DS> (probably another Brit saying that doesn't cross the Atlantic :-( ) Nope, we've got that one too. And it's just a tiny cake, only wafer thin. No need for a bucket. ;-) -- Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
