Hi Irek, I. Szczesniak p??e v ?t 26. 05. 2009 v 22:43 +0200: [...] > > Can you cite any evidence of this? I think a lot of excellent software is > > delivered via SFW. > > Excellent software which is poorly integrated into Solaris. >
I agree that some parts of SFW are not well maintained. And yes, sometimes it is problem of SFW consolidation design but it is improving just these days. But it is not situation of this Perl ARC case. > Evidence 1: Configurations changes in random intervals, i.e. > postgresql using select() instead of poll() and MAP_ANON depending on > system load of the build machine. postgresql tcl is broken in some > SXDE/SXCE releases because it picks the wrong libraries randomly, too. > There are two different issues, not optimal integration (can you send me CR numbers for select/poll and MAP_ANON RFEs, privately, please?) and Postgres build process in SFW (on-going improvements there). > Evidence 2: Software in SFW uses suboptimal compiler flags. Software > delivered via SFW uses only SFW default flags or the flags discovered > by autoconf. Some bits are even delivered without the optimizer > enabled. These are not problems of SFW, these are problems of that software. Fill RFEs. It will not be automagically solve by moving it to different consolidation. > Roland Mainz said he'll take a look but never responded to that subject. > Who will disturb Roland from ksh93 project he will be "disturbed" by me ;-) > Evidence 3: API stability. Shall we discuss the random disappearance > and appearance of features here? Its rarely noticed that adding > software to the build machines silently enables new or changes > existing features in the SFW software. > But this would not be solved by different consolidation. Also, I went through the integration process of new library to SFW few weeks ago and C-team is doing very good job during the process to avoid such situations. Mistakes can happen, of course. If some documented feature disappear without proper ARC process, then it is bug. As Nico wrote, SFW has the same ARC process as ON. If some new feature appear withour ARC, then it is private feature. And you can fill RFE/bug, of course. > perl 5.8 in ONNV was added by someone who knew the shortcomings of > perl's automated configuration and wrote his own Makfiles to avoid > them. Putting perl into SFW will those shortcomings appear again in > the system perl installation. > That is responsibility of Perl maintainer. He can wrote his own Makefiles even in SFW. He can fix perl's automated configuration shortcomings. But again, it is not SFW consolidation problem. By your logic even Sun Studio should be part of ON gate. I think there is no real ARC issue, only possibility of buggy integration. Best regards, Milan
