John Plocher writes: > This is a *draft* opinion intended to be used as context for a vote. It > needs wordsmithing in several places, including the "not architectural" > sections in section 4. Contributions of "better words" would be very > much appreciated.
It does need some wordsmithing, but that's not my main concern with it. Besides not really saying anything new (we've been immersed in the 32/64 bit issues for more than a decade now), and apparent improper handling of a private email conversation, I think section 4.3.2 is completely out of step with the goals of the Indiana community in building a reference distribution built on community involvement. The real issue there is that distributions need to set boundary conditions (including a set of platforms on which to run, which is explicitly *NOT* what this case is about, despite section 4.1.1), and not some architecturally irrelevant argument about who has 'standing' to make those distributor decisions. Because I think the out-of-context excerpt in 4.3.2 appears to suggest that Sun has the final say here, and not the distributor, and is thus quite destructive on the face of it, I would vote against this opinion as drafted. Without that section, I'd abstain. Without a project supporting an actual 64-bit-only platform under review, or some stronger policy about the requirement for 64-bit cleanliness (and not just "if you want, and you're not magical FOSS"), I don't think this says anything useful, so there's no reason to vote in favor. (Of course, if it provides some operational advantage, I have no problem with the original and now blown-out-of-proportion proposal to switch the SPARC GNU coreutils+bash to 64 bit. I also don't think it's an architectural matter at all, so we really didn't need to review this implementation choice. Why are we here again?) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
