James Carlson wrote: > Wyllys Ingersoll wrote: >> It is unreasonable to burden >> the teams that want to bring FOSS code to Solaris to also put in additional >> effort to fully "Solaris-ize" the code in question. > > If the ARC adopts that position, I think that'll be a substantial change > in direction. The stated policy up to this point was that "free > software isn't free from cost," and that part of the burden of > integrating into [Open]Solaris itself is that the software and/or > documentation and/or packaging may well need to be modified in order to > be compatible with the system. Doing this might mean engaging the > upstream community, or applying diffs, or forking the source, or perhaps > some combination of those approaches. > > I'd thought that this understanding is exactly what the whole "kitchen > sink" scheme for random FOSS integration was based on. > > Has this changed?
Note that I said "fully". I'm not advocating abandoning our quality or integrating obviously broken code. In the past when I have integrated FOSS code to SFW, I *have* made patches to make it compile better, fixed bugs, etc and also engaged the upstream community to accept the changes back. Whether or not they accept the fixes is beyond my control. The changes being discussed for Pth are not bug fixes or build modifications, they are a change in the entire design of the library. The whole point of Pth is to be a "Portable" thread library that is self-contained and does not depend on any other thread libraries. Even if the changes being discussed really are "low hanging fruit", it still amounts to violating the goals and intent of the package as far as I can tell. The real "fix" (if you can call it that, since nothing is actually broken in its current state) would be to modify the consumers of Pth (GnuPG in this case) to use the native code and eliminate the need for Pth. I will investigate the level of difficulty in doing just that, but I am not going to rewrite Pth to use Solaris threads just because we think ours is better (regardless of whether or not it really is) especially if the code already "just works". >> If integrating into ON, >> then the argument is stronger, but for SFW packages ideally we like >> to just drop in the tarballs from the upstream community and apply a >> minimal amount of changes to get it to compile and work. > > That's a darned shame. Compiling things and tossing them over the wall > is fine for a "contrib" repository or something like the old /opt/sfw > "Companion CD," but I don't see how it makes any sense for integrated > software. > > Moreover, I don't see how consolidation matters here. Consolidations > set build and integration rules, but from the user's point of view, it > matters not whether "SUNWfoobar" was originally integrated via ON or > some other consolidation. They're all the same to a user. Thus, the > same quality had better be present, or the quality of the result will > actually reflect the weakest part of the chain. > Consolidation matters to the project team doing the integration work, that is my point. ON rules for integration are significantly more onerous when attempting to integrate a FOSS package that already has an established configure/compile/install workflow and it is much harder to resync with the upstream when new releases come out. > If compile-without-changes is the intended new direction, why not just > switch to Linux? It'll be way easier, and will have essentially similar > results. Compile-without-changes is not the new direction as far as I know, but it certainly is a goal. The direction I've heard in the past for SFW projects is to apply patches as necessary and work with the upstream community to accept them so that we can eventually get to the point where we don't have to apply patches anymore (we ultimately would like to be "compile-without-changes"). -Wyllys
