Stefan Teleman writes:
> The PHP Group has *no interest whatsoever* in Solaris. This may change in the
> future, but it is highly unlikely to change within a predictable timeframe.
Perhaps there's a miscommunication here.
I somewhat agree with John about the design pattern issue, and I agree
with his "would like to see" comments about pushing the changes back
upstream -- I think the same thing is true in many other projects --
but I can't see gating integration on any such thing.
The project team is the one that has to sign up to maintain any local
deltas. I think it's fine advice to say "try to minimize by pushing
upstream," but not something that ought to be a requirement as it
slaves Solaris architecture to third-party politics.
> I would caution that tying the approval of this ARC Case to the acceptance
> upstream (by the PHP Group) of our build configuration tweaks and directory
> structure changes, is functionally equivalent to derailing this ARC Case
> indefinitely.
A process note for others listening in on the discussion: the above
text implies something other than what "derail" means in this context.
"Derail" actually means "this isn't a fast-track; it requires a full
review." It's not a pejorative term, and there's no way to apply a
time span to it ("indefinitely").
Cases that either require extensive discussion (this one might be
that way) or that require a written ARC opinion (John's design pattern
request would need that) cannot be handled as fast-tracks. They're
derailed so that the meeting can happen (if needed) and the opinion
written (always required).
The right term would be "deny," but I don't think this case is near
that.
--
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
