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.
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
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
