Michael,
> Rainer Orth wrote:
>
> > I think here's an important misunderstanding: this is not how free software
> > works. If Sun as a vendor or the OpenSolaris community as a whole rely on
> > GCC in some way (as Sun has done for the initial amd64 port), it is their
> > responsibility to test GCC on their platform, make sure that it continues
> > to work seamlessly, and make sure that new features requiring
> > platform-specific code are supported on Solaris as well.
>
> Sun has done the first two things:
>
> 1) tested gcc 3.4.3 on the platform
> 2) make sure that it (gcc 3.4.3) continues to work seamlessly (we don't have
> the
> expertise for this at Sun, so thus the contract with CSL)
>
> But, Sun has not done the third item (support new features as they come out).
> Why not? Well, I think there's an important distinction between supporting
> *a*
> gcc compiler in S10 (which is critical for many users/customers/developers of
> Solaris/OpenSolaris), and supporting the "gcc compiler release stream"
> (certainly nice, but not critical for most user/customers/developers).
while this is somewhat understandable from Sun's point of view, I don't
think this is wise: gcc is critical infrastructure for many Solaris users,
and they see that it works seamlessly on other platforms (both Linux and
commercial unices like AIX and Mac OS X), with full support for all
languages, as of every release. They will often depend on it, and newer
features/runtime library support whatsoever, in recent releases, only to
find that this is not equally the case on Solaris.
> Sun did choose gcc 3.4.3 (branch) as the first supported gcc compiler. I
> don't
> think that necessarily implies any timetable for Solaris/OpenSolaris support
> of
> subsequent versions. Solaris/OpenSolaris should be able to support new
> versions
> when it makes sense to do so, not just when the next version comes out.
I think we have two issues here: which GCC releases to bundle with
(Open)Solaris, and which GCC releases are well supported on (Open)Solaris.
The former question certainly needs to be investigated carefully,
considering support costs, migration problems etc. This is the same for
Linux distributions etc. which probably don't ship every available GCC
release, but select one and stay with that for the release's livetime. The
latter question is different, IMO: since GCC is quite a moving target,
catching up with recent developments after months or even years of neglect
can be cumbersome and costly, and since many Solaris users have come to
depend on newer GCC versions even if they are not bundled with Solaris, it
is our responsibility as a community that Solaris becomes and remains a
first-class citizen for GCC development.
> So, when does it make sense to do so?
>
> I think this thread is an excellent start at this discussion, because we're
> getting at some of the core issues involved in deciding when and how to
> upgrade gcc:
>
> - gcc compiler & library changes causing binary incompatibility
> - stability
> - support (including the branch question)
> - changes needed for OpenSolaris itself (which haven't all been made yet)
>
> Are there others that I've missed?
I can't see any offhand. But this addresses only the question when to
integrate a newer version.
> > Nobody else will
> > do this for us. This is how other vendors like IBM, HP, Apple and the
> > Linux distributors handle this: many of them invest considerable time and
> > man power to GCC development.
>
> There's a built-in assumption in this statement that free software works the
> same way for everybody (it's an "Appeal to Common Practice", I think. I just
> learned that term on Slashdot, which I was reading during the day for
> educational reasons only, I swear! :-) :-).
>
> I don't think it works the same for everybody -- even companies that depend
> upon
> free software as a critical part of their product do not invest time and
> manpower into development. In my experience (open source XML parsers),
> vendor
> participation in open source development was the exception, rather than the
> rule, even from companies who used the open source component as the core of
> their application.
This may be a possible cause of action for software that is relatively
platform-independent. For highly platform dependent stuff like a compiler
and its runtime libraries, I don't think this works out: unless the users
of the platform (i.e. the OpenSolaris community) make sure GCC is tested
regulary, bugs and regressions are reported as soon as they are detected,
preferably fix them themselves (or pay someone to do so), and implement new
features requiring platform dependent code, GCC's support for the platform
is guaranteed to deteriorate quickly (as I've observed myself e.g. for
Tru64 UNIX and IRIX), and it will require a considerable effort to get this
fixed at some later point in time. Therefore I think it makes more sense,
both for Sun and the community, to make sure GCC works seamlessly for every
release, even if they don't get integrated into OpenSolaris, both to reduce
future work and for the benefit of GCC users on OpenSolaris.
> So, I guess what I'm saying is that for OpenSolaris, I think we should do
> what's
> right for OpenSolaris, not just do what others have done.
True enough, but you can see other cases where the OpenSolaris community
invests heavily in upstream open source software: JDS/GNOME is a case in
point where the desktop community makes sure every upstream release is well
supported on Solaris, so they can decide at every point to integrate the
upstream release if the time is right from an OpenSolaris point of view.
If you neglect this (as has happened after GNOME 2.6), you have to invest
large amounts of time and money to catch up with intermediate developments,
which will be much more costly than making sure the upstream releases keep
working fine.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
opensolaris-discuss mailing list
[email protected]
