> The configure.in portion of the original patch was withdrawn. The only
> remaining part is an ifdef around a config_require in a header.
OK - I hadn't spotted that. (It's been a more than usually hectic week!)
I'm a lot less bothered about the potential ramifications of this patch
in that case.
> The patch removes a config_require if WIN32 is defined. I have verified
> theat Cygwin does not define WIN32, and does include the module....
> .... the patch does not affect cygwin's current (unknown) status.
Ummm... but now I'm confused again. You say you know it works on Cygwin,
then you say that the Cygwin status is unknown. Is it known to work on
Cygwin or not?
I'm happy that it *should* do - but have you (or anyone else) tried
this with a clean download and verified what *actually* happens?
Anyway - I don't really care either way. What I'm more interested in
now is the release process quality control mechanisms.
DS> The whole idea of a code freeze is that it actually
DS> *freezes* things - accepting a loss of flexibility
DS> for a gain in stability.
RS> But it doesn't mean a complete loss of flexibility, or we might as
RS> well just ship when we freeze and fix bugs in the next release.
Remember that we're talking about a "Release Candidate" here - not
a pre-release. We're saying
"this exact tarball is what we want to release - does it work?"
As soon as you change anything, it's no longer the same tarball.
It's fine to fix serious problems, but then we'd need to cycle again.
A release candidate will be around for 7 days max, and no-one should
be using it after that. A full release may be around for months.
The two are not comparable.
Dave> The thing that really annoyed me was the suggestion that a 5.3.pre3
Dave> release wouldn't be necessary.
RS> I said *I* didn't think it was necessary, because I'm confident that
RS> this piddly little 2 line patch isn't going to break anything.
And as I've said two or three times already - both Wes and I have made
"piddly little changes that weren't going to break anything" immediately
before a release. And we were wrong.
Dave> It only takes one minor slip that isn't picked up to fuck things
Dave> up completely.
Dave> I've done it, Wes has done it, we don't want you to do it too.
RS> Oh, rest assured, I've done it too.
But not immediately before a release, with no chance to spot it.
That's a fairly exclusive club, and we want to keep it that way.
Dave> So it comes down to one simple question - is this
Dave> fix worth pushing the whole release back a week, or not?
RS> The week delay was the reason I didn't want another pre-release.
That's fine - then it doesn't go in.
That's my reading of the "quality control" for releases.
We come up with a "release candidate" tarball that we're happy with,
change the version tags (and *nothing* else) and ship that.
Documentation, etc isn't the same - mistakes there wouldn't do the
same damage. But anything that potentially affects the code and
compilation (including embedded documentation) is verboten without
another RC cycle.
RS> I almost suggested simply doing rc3 on Monday
Yup - that'd have worked.
The reason I suggested pressing RCs every Friday was to make sure things
kept moving. I've no objection to them coming out more frequently, or
any great religious attachment to Fridays. (I'm Christian, not Muslim!)
Just as long as there's a clear period between the final RC and the actual
release. Ideally a full week - at the very least a "working week".
So a minimal change first thing Monday, and a release on Friday might
*just* be OK. But by Tuesday or Wednesday, then I think we'd need to
be looking at slipping the release itself.
Anyway, that's my take on how things should work. I've wasted enough time
on this now, and really ought to be getting on with other more urgent stuff.
Wes can chip in if he sees fit. Otherwise I'll just leave you to get
on with it.
Dave
-------------------------------------------------------
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
