Joerg Schilling wrote:
> Brian Utterback <brian.utterback at sun.com> wrote:
>
>
>>> OK, if I get the right to block the RTI for the next unplanned (*) Sun tar,
>>> I have no problem with this point of view. If this is not possible, it
>>> would
>>> help a lot if there was a more realistic approach.
>>>
>>>
>>> *) Because it introduces new "inherited waste"
>>>
>
>
>> To take this to the next step, Meem can *ask* the C-team to block the
>> RTI, but they do not have to act on his request. So, too, you can
>> do the same. At this point you don't really have access to the C-team,
>> but until the C-team is opened up, if you have a legitimate point I am
>> sure someone at Sun would relay that point to the C-team if you
>> requested it.
>>
>
>
I know I'm going to regret getting involved, but....
Have the extensions escaped in to the wild? (By that, I mean, have they
been released to Solaris 10 customers? I don't care about Solaris
Nevada.... we can tolerate breakage in Nevada as long as no stable
release has been made, I think.)
If the extensions have escaped, then it is probably too late to do
anything about it, and we just need to figure out a way to improve
cooperation in the future.
If they have _not_ escaped into Solaris 10, then can I suggest that
Joerg, who's obviously an expert in these details, and who seems to care
passionately about it, figure out how to reimplement the features to be
more compliant with POSIX 2001.1? He can send diffs to the tar folks,
and I _suspect_ that as long as code is delivered without animosity,
that they will be happy to integrate the changes.
In any case, fighting is not going to solve the problem.... we need to
look constructively.
For the case of PSARC, if there is not a PSARC case for these
extensions, then can a PSARC representative kindly slap the project team
that integrated these features on the wrist? Changes that are customer
visible ... including file formats... need to be ARC'd. I can certainly
understand Joerg's frustration if he was not given an opportunity to
give feedback into the process. (Although I do not know whether or not
he _was_ given such an opportunity.)
-- Garrett
> OK, then please back out the changes to Sun tar related to "Trusted
> Extensions"
> ans let us start a technically based discussion _how_ these extensions should
> be implemented.
>
> I did never see a related PSARC case, so it seems that this change was made
> without permission anyway.
>
> We cannot continue to add new "inherited waste" to Sun's tar implementation.
>
> The POSIX.1-2001 tar extensions are a clean method that _definitely_ should
> be
> used for all new features. As this was not done for the ZFS enhancements as
> well for the "Trusted Extensions", something did go massively wrong. Since
> the
> year 2001, there is no reson to continue to use deprecated POSIX.1-1988
> methods
> anymore.
>
> J?rg
>
>
