Dave Shield wrote:
<snip Mythology 101>
No - there's certainly a case for including this fix in 5.2. Personally I don't think it's significant enough, but I'm a Unix bigot, so MinGW support isn't particularly high on my list of priorities.
The import of the platform is not the issue at hand. If it were a propriatary embedded platform and had compiled and then was suddenly broken in a release candidate I would still vote to have it fixed. Last minute band-aids are a fact of life as you well know. I tested the patch not only on a Windows machine with a MinGW build but also on a Linux box.
But there were three things in particular that I didn't feel you were paying sufficient attention to:
- just 'cos two people have tried something and found it works, is not sufficient to guarantee that it doesn't break something else. It only takes one minor slip that isn't picked up to fuck things up completely. I've done it, Wes has done it, we don't want you to do it too.
Agreed.
- changes to the configure environment are never "only".
It's the one piece of this overly-complex morass of code that is
the least well understood by any of us. And it's the one piece
that holds more potential to break a wide variety of systems than
anything else.
You may have "visually inspected" the configure.in patch. Do
you seriously expect me to believe that you've also checked the
configure script itself? That's the bit that *really* matters!
The configure patch was not even needed. The MinGW build worked with only the interfaces.h patch.
- some four hours after your message stating that things have been thoroughly tested and found to work (pouring scorn on my concerns), Alex asked if anyone had tested this under Cygwin. I've still to see a positive response. "I suppose I should" doesn't count.
I am not sure that anyone has tried the package on Cygwin in quite some time. I know that I have not been actively working on it. That was my slip this time.
The other factor is that we've been pretty flexible about these things in the past.
And as I've tried to make clear, we've probably been *too* flexible in the past. I thought we'd agreed to try and be a little more rigorous about such things. The whole idea of a code freeze is that it actually *freezes* things - accepting a loss of flexibility for a gain in stability. It may be inconvenient, but the whole idea of rules and guidelines is that they provide an objective framework to work in - and they need apply to everyone, not "everyone else".
I thought the whole idea of allowing voting was to recognize that there are occasional exceptions. If this patch was any large in scope, untested or coming at the very last minute, I wouldn't be pushing it.
Unless I misunderstood Wes completely, the idea of voting was suggested for new features post-5.2 and before breaking off 5.3. It was not intended to completely bypass the quality-control mechanisms that we have (belatedly) put into place.
The thing that really annoyed me was the suggestion that a 5.3.pre3 release wouldn't be necessary. If you do *anything* to the configure script, then I definitely think we need another pre-release, to make sure that we haven't broken some really obscure environment somewehere.
Again, the fix did not include a configure patch as originally anticipated. For what it's worth my feelings on the matter are that if Solaris, AIX, or Free BSD had been working and were broken we would fix it. We know about the problem, and we know the implications of fixing it. We also know that the fix works on the platforms that we have access to to build on.
I don't for one minute believe you have, but I don't think we should take the risk. So it comes down to one simple question - is this fix worth pushing the whole release back a week, or not? Otherwise I think you're trying to have your cake and eat it.... (probably another Brit saying that doesn't cross the Atlantic :-( ) Dave
Naw, we have that one here as well :-)
Andy
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
------------------------------------------------------- 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
------------------------------------------------------- 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
