GCC releases [was Re: ia64 libjava java-signal.h build failure]
Bryce McKinlay
bryce@waitaki.otago.ac.nz
Mon Apr 23 19:20:00 GMT 2001
Mark Mitchell wrote:
> The basic core of our disagreement is this philosophy:
>> Alexandre> timing; the earlier we enable it, the earlier we'll get
> Alexandre> reports in case of failure and the earlier we'll get
>> Your approach is aggressive -- assume it works, and then disable it
> where it doesn't. Mine is conservative -- assume it's broken, and
> enable it where it's known to work.
>> In my my opinion, your approach is sensible for the mainline -- but
> mine is sensible for the branch.
Despite some disappointment about the current Java situation, I agree
with Mark here. The whole point of having a stable branch is to get it
working as much as possible and then not try to do things that are going
to break it. At some point we have to admit that the release is never
going to be perfect and never going to support everything everywhere, and
just get it out there.
I hope that in the future, releases can happen much more frequently (3 -
4 releases per year seems like a reasonable goal, instead of one every 2
years!). This would help to alleviate the "just one more
feature/fix/port" syndrome since waiting until the next release won't be
such a big deal.
regards
[ bryce ]
More information about the Java
mailing list