John Plocher wrote:
> Joseph Kowalski wrote:
>> John Plocher wrote:
>>> You are right in one aspect - as a /suggestion/, this is NOT intended
>>> to be a predicate for approval of this case. In formal ARC-eese, I
>>> would
>>> like to see:
>>>
>>> TCR - articulate this design pattern ("just like Perl...")
>>> into a formal BestPractice that can be published on the
>>> ARC Community pages (I will happily help with the logistics
>>> of making this part happen), and
>> Can't TCR that. A TCR must be written to be explicit such that no
>> further
>> review is required. I think I'd like to review the "design
>> pattern". Its got to
>> be part of the materials before this can be approved (or another
>> case, upon
>> which this is dependent).
>>
>> - jek3
>>
>
> We seem to have several precedents - Perl, Java, XPGn, versioned DSOs,
> Multi-Installation and Management of Layered Products for Java ES, etc
> that should be brought into some sort of alignment here.
>
> I'm reluctantly OK with making this a NEED SPEC; I was hoping to decouple
> it from the approval cycle for the project, though. That is, I'd like to
> say something like
>
> This project is approved now, and one of its deliverables is the
> BestPractice that codifies the multi-version install design pattern
> that it used.
>
> rather than
>
> This project needs to construct the Best Practice before it can get
> ARC approval.
>
> -John
I'm not willing to allow a project to integrate with a structure which
assumes one delivery model which may not be in-line with the Best
Practice they are asked to deliver.
Either as a TCR, or as a requirement of the case, they don't integrate
until it happens, so I fail to see what is gained.
As Advisory, there is no guarentee it ever happens.
- jek3
