Nicolas Williams writes:
> The ARC should want to make sure that Unison's shortcomings are properly
> documented. The ARC can't expect i-teams to fix the FOSS they are
> integrating -- only the how it is integrated.
Really?
I don't think that's true. I think it's right and proper for the ARC
to ask the I-team what it can do about any problems that exist,
regardless of where the code was obtained -- whether written by the
submitter himself, purchased from some vendor, or downloaded off of
the internets.
The I-team can certainly respond: "we can do X, but we can't do Y,
because it'll {cost too much, confuse users, break feature Z}." Those
arguments may or may not sway the ARC members, depending on the
severity of the problem. If it's bad enough and the I-team is
intransigent, then the right answer is to derail (if fast-track; does
anyone do full cases anymore?), TCR it, and let the project team
determine how to handle the problem.
I think the ARC would be derelict in its duty if it simply said "FOSS
means no expectation of source change." That may be true of some
projects, but certainly not of others, and the ARC should not be
presuming one magic answer for all cases.
--
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
