I. Szczesniak wrote:
> On 5/26/09, James Carlson <James.D.Carlson at sun.com> wrote:
>
>> Rich Burridge writes:
>> > Perl 5.10.x is binary-incompatible with 5.8.x, so it will be
>> > necessary
>> > to declare 5.8.x EOF in OpenSolaris, and remove it in a later
>> > version.
>> > A separate case will be submitted for this.
>>
>> Is the EOF announcement for 5.8.x part of this case (with only the
>> removal being a future case), or are both parts for a later case?
>> (I'd argue that the former is both simple and likely makes more sense
>> here; if it's the latter, then please explain the status of 5.10.x
>> alongside 5.8.x.)
>>
>> > Unlike previous releases, 5.10.x will not integrate in to O/N, but
>> > will instead move to SFW.
>>
>> I'll be glad to see it go (eventually) for the improvement in build
>> time,
>>
>
> Is this the only justification? Bits delivered via SFW commonly have
> substandard quality and are very poorly integrated. I fear that
> putting a critical system component such as perl into SFW will affect
> the quality of Opensolaris as whole piece.
>
There are plenty of "cricital" open source bits in SFW. The quality of
the software delivered into any consolidation is a function of the
commitment by the software owner to is proper configuration, care, and
feeding. Unfortunately, there are varing levels of commitment to the
care and feeding of software in Solaris. This is true across all
consolidations, not just SFW.
If you find any of the software delivered into SFW (or any other
consolidation) to be inferior, please file bugs against it. You might
find that the owners of these bits are more than happy to work with you
to resolve issues. If they are not, we need to know. When the software
integrated, the owner agreed to a level of commitment to it's care and
feeding. For the various bits of open source software that come into
SFW, that level of commitment varies from tracking the community
releases and fixes to more active participation.
On occasion, software is purposefully held back or crippled for reasons
that may not be readily apparent. Though, I would say that's the
exception, rather than the rule.
> If there is no other justification build time please keep perl in
> ONNV. Or derail this case and write memo why perl should move to SFW.
>
Though I agree that ON build time isn't a justification for moving from
ON to SFW, I am sure that they have other valid reasons to do so. That
being said, with the exception of requiring contracts for use of
consolidation level (or lower) interfaces, which consolidation a
particular software component delivers to isn't an architectural decision.
-Norm
