These arguments are all quite familiar- I'm not really moved one way or
the other.

The point here is that major changes need to be very visible on a
product's schedule. You can argue that it isn't a major change- but I'd
assert that any toolchain change *is* a major change.

I'm *not* arguing against the change- I don't know nearly enough to have
an opinion. I *am* commenting on how major changes coming in with little
notice often add substantial delays. Furthermore, lack of putting such
changes up in such a fashion that a folks in distributed development
environment can then adequately plan/protect themselves so *their* stuff
is protected is also an issue.

Look- if Alexander hadn't said anything, I *probably* wouldn't have
noticed.  However, he felt that this was important enough to tease
people with a "10 minutes until the bombs start falling" mail message.
It's not unreasonable to raise this as an issue.

Or if you think it *is* unreasonable, we can go offline so I can discuss


On Sun, 1 Sep 2002, Peter Wemm wrote:

> Matthew Jacob wrote:
> > This would have been a firing offense at several companies I've worked
> > at. It's not unreasonable to take a lesson from *why* these things are
> > firing offenses and start to raise queries. I've done so. Duty is done.
> > Go back to sleep.
> Would you rather that we ship with a known broken prerelease compiler?
> Would you rather that we changed from 3.1-prerelease to 3.1.1-release?
> gcc-3.2 *is* 'gcc-3.1.1 + ABI bugfix'.  They renamed the 3.1 branch to 3.2.
> All future 3.1.x releases will be called 3.2.x.
> Cheers,
> -Peter
> --
> "All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to