Wyllys Ingersoll wrote:
>
> I disagree. For many weeks now the submitter has answered the
> questions and made all of the corrective actions requested by the ARC
> on this case and now there is talk of derailing it? I don't think
> any architectural issues were found with the project. The
> documentation is weak, but the submitter has agreed to work with the
> open source group that owns it to address the doc issues.
That's not the same as "fixing" the documentation prior to delivery.
What if the upstream group doesn't want the doc fixes? What if it takes
too long? The revised documentation is not "supplied" here, so we can
only review based on the documentation that was in the case materials.
> The "auditable administration" question was answered already - there
> is no auditable interface for any PAM configuration files or any other
> files that are managed via "vi" (or whatever editor) for that matter.
I didn't see the answer in the mail log. Managing files via "vi" is
certainly possible, but it isn't clear to me that "vi" is the solution
for system administration. "vi" can't be audited, so its reasonable
that a CLI be provided which *can* be audited, and also "controlled" via
RBAC.
All in all, the setup and administration of this subsystem seems very
half-baked to me. While this is fine for the wild and woolly world of
Linux, I'm not sure it's appropriate for Enterprise Grade Solaris.
(The fact that maybe the powers-that-be may (or may not) have decided to
abandon Enterprise Grade Solaris in favor of Web-2.0-RedShift-Indiana is
beside the point. We -- meaning PSARC -- haven't been given any
guidance yet that we should change the criteria by which we review
projects Or if we have, I'm unaware of it.)
>
> Discussions over how best to merge FOSS and ARC needs is something
> that should be discussed outside of this case.
Yes, although this case, and ones like it, seem to be justifying a
reduced level of review/requirements based almost solely on the fact
that the code is FOSS. I am not aware of any precedent or guidance for
handling FOSS with reduced requirements at ARC. Perhaps there is an
unstated (and unsubmitted?) case dependency here -- this case dependent
on some kind of precedent decision or other case indicating that it's
okay to skip or waive normal architectural rules for FOSS. Anyway,
there is a reason that I raised that issue *separately* on arc-discuss.
> The project team has been playing fetch-a-rock for too long. The
> final specs have been submitted, I think Darren is planning on putting
> them in the case dir very soon. This case should be approved so the
> team can move ahead.
As I indicated earlier, if the pressure is one particular customer, why
not send binary relief to that one customer, while the project team
works to fully address concerns to make this bit of software up to the
same quality (and I'm not just talking about code quality/robustness
here -- but also supporting documentation, adherence to Big Rules, and
fit-and-finish issues of the kind we normally require for Sun-developed
software.
-- Garrett
>
> -Wyllys
>
>
>
>
> Mark A. Carlson wrote:
>> Garrett,
>>
>> I see this kind of phrasing a lot lately. Let's go ahead and derail
>> then.
>> Count me as "supportive of such action" as chair.
>>
>> -- mark
>>
>> Garrett D'Amore wrote:
>>> ... I don't feel strongly enough to derail on my own here, although
>>> I would be supportive of such an action if another member decided
>>> that was appropriate.
>>>
>
