Roy T. Fielding writes: > On Aug 8, 2007, at 12:25 PM, James Carlson wrote: > > For example, if there are two deliveries of /usr/bin/ls -- one that's > > Solaris and the other that's GNU (for instance) -- do we force every > > script writer depending on 'ls' to add compatibility logic to support > > both? If not, then do we end up with a sea of mutually incompatible > > things? > > Product names are not left up to chance -- they need to be owned by > the organization as a whole.
We must be using different terms here, because "product" means something far afield of what I thought we were talking about -- with "Solaris" being one example of a product. It seems a surprising term to use right here, as it's in the realm of marketing and trademarks, not architecture or governance. I suspect you mean "delivered file or object" or some accumulation of those (such as "software package" or "project"), right? > I meant that CGs should be allowed to > compete on solutions to overlapping problem areas, not on overlapping > product names. In any case, that concern is only relevant if there > is a common distribution under which conflicts can be determined, so > I would expect such an ARC to be specific to one named distribution > (if there is more than one). Yes, that's what Brian Utterback was essentially proposing. Such a thing makes me quite nervous, as I don't think it's the sort of complexity that can resolve well. Things work fine if the competing schemes resolve themselves quickly without accreting too many dependent projects. They work very badly if they result in forks, because (as I mentioned before) it's easy to get yourself into a world populated by mutually-exclusive choices, and that makes both using the system and designing new features very hard. If we must screen for conflicts by distribution (rather than globally), then, for a given project, I would like to see both substantial justification for the duplication, and some hint about how we get back out of the mess before it's too late. I'd expect conflicting projects to have a rough time with architectural review in some cases. -- 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
