Roy T. Fielding writes: > I think the ARC should understand that attempting to pick > and choose from open source alternatives while making changes to > those products is not a feasible course of action. It is okay to do
I think the project team should understand that ARC members not only understand these issues, but many of them are also themselves contributors to and maintainers of external open source software, and have been for many years. We didn't just collectively fall off the turnip truck. (In my case, yes, I've seen horrible problems on certain Linux platforms because of the misguided ways in which the distributors choose to hack at the PPP code. The solution to many problems is to rip out the hacked vendor code and replace with the original distribution. It's certainly not an unknown problem.) In this case, we're talking about system architecture. How that actually gets designed, implemented, and managed is the project team's responsibility. In other words, if we were to find that using the common crypto routines was a requirement for operation on Solaris (I don't think that's happened, but it's one of the issues being discussed), then it's up to the project team to determine what to do about that. Yes, forking might be a bad decision on their part. They'd likely be in better shape overall if they can contribute the changes back to the upstream repository. I don't believe it's acceptable to have shackles applied to system architecture. It's not reasonable to say that because some arbitrary developer somewhere in the GNU universe thought that "Foo" was a good idea, then Solaris _must_ also believe the same thing. Doing so is abdicating our responsibility. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
