Dave> I'm getting fed up of always playing the Cassandra role.
Robert> Being a simple uneducated yank, I don't get the reference,
Cassandra, daughter of King Priam of Troy.
Freelance soothsayer - always predicting doom and gloom,
like getting the shit beaten out of them by the Greeks.
Cursed by Apollo to always predict the truth, but never to be believed.
Robert> I'm sorry that I've frustrated you, but I'm just exploring the
Robert> boundaries here.
Perhaps I over-reacted - I'm sorry.
But I got the impression from the previous message that you
felt I was being excessively over-cautious, and it hit a nerve.
> And as I said in the previous message, I think this fix meets the criteria
> we've established. Maybe it doesn't. Maybe at this stage, 'breaking the
> build' means breaking all platforms(eg an problem building snmplib),
> not just a single one. I'll never know unless I ask.
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.
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.
- 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!
- 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.
> 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.
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
----------------------------------------------------------------
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
