Nicolas Williams wrote:
>> I understand what de-railing means. I'm reacting mostly to the
>> withdrawal of the case. But also, when it comes to FOSS, the ARC can't
>> be de-railing too often, else the process will be unbearable, which is
>> partly why I asked if it wouldn't be better if all non-core FOSS always
>> went through /contrib first: partly because the ARC would be less
>> relevant to FOSS then, partly because the i-teams would get instant
>> gratification, partly because it'd give the potentially controversial
>> cases time to soak.
>>
Garrett D'Amore wrote:
> I agree that it makes more sense for things that really are not fundamental
> portions of the OS to be integrated into /contrib first, and maybe even
> only.
>
> I'm not a huge fan of the idea that we *have* to integrate everything
> under the sun in /release, if only because the process of doing so, and
> supporting the bits post integration, can quickly become daunting.
I agree that it would be better to integrate these FOSS "familiarity"
packages in /contrib, at least initially. It would be a more accurate
portrayal of what people are actually getting from us.
Part of the problem seems to be that there is no good place to keep the
source code. The choices seem to be:
(a) Keep the source in an unknown, uncontrolled location (e.g. someone's
home directory) and integrate the package in /contrib. Someone also has
to remember to rebuild the package when needed and resubmit to the
repository.
(b) Integrate into SFW, which takes care of source code control and
regular building and delivery. But then the package is part of the WOS
and gets delivered in /release.
Couldn't we partition SFW into "release" and "contrib" trees and get the
best of both worlds?
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
