I am sorry to read this from you.
I get the impression that you missunderstand OpenSolaris.
You have been on the OpenSolaris Summit in September 2004 and for this
reason, I would expect that you remember the rules that have been named there.
OpenSolaris can only work if experts from inside and outside Sun work together
and if the only thing that counts is whether a person is an expert in a specific
topic. It must be possible for a non Sun person to block a putback from a Sun
internal person if it is not reasonable and I would expect a more friendly way
of living together with respect to putback rights.
It must be possible to cause a backuout of a putback that tried to introduce
new code based on obsoleted methods.
Keith M Wesolowski <keith.wesolowski at sun.com> wrote:
> There are a few important points here:
>
> - The C-team has the last word on integration. One may ask them
> for cause to deny or hold integration, but one cannot force them
> to do so.
Who is the "C-team" and shouldn't they ask experts if in doubt?
> - The context here is one in which a reviewer has made comments he
> feels require action and no action was taken by the implementer, a
> rare situation (and not one I expect to occur in the case of
> ksh93). Not all review comments are "fix this or I'll block you";
> it's normal to get some pushback on things that are seen as out of
> scope or where the reviewer simply hasn't understood the intent.
Well I did make my comment just because I did read this "fix this or I'll block
you".
> - You're not allowed to obstruct others' work just because you
> don't personally feel it's worth doing, or because you're feeling
> vindictive and spiteful. Concerns raised should be of a technical
> nature and should relate to the correctness of the particular
> change.
A really interesing point!
I get the impression that exactly this is done with Roland and me.
I have no problems with real technical reasons if the way they are used
does not cause the impression that someone's work should be blocked for no
reason.
> You can ask the C-team to hold or deny integration of any changes to
> tar because you personally feel that your program is the only one in
> the universe worth using and think that working on anything else is a
> waste of time. However, if you're not a reviewer, the reviewers are
> happy, the work appears to be complete, and you bring petty, selfish
> reasons, I hope and expect that the C-team would ignore you. With any
> luck they'd also file away a mental note to ignore you in the future.
Well, I would hope that C-team did block people who create extensions to Sun
tar using deprecated methods. This has been done with e.g. the ZFS enhancements
for Sun tar and the fact that deprecated methods have been used is going to
block _me_ and will in future cause a lot if unneded effort. This is because
someone who should have asked an expert did not ask in time and now I will be
forced to implement useless code using deprecated POSIX.1-1988 extensions for
features that already have been implemented on top of recent POSIX.1-2001
extensions.
BTW: the recent Trusted Extension related changes in Sun tar are also based on
deprecated methods!
Why is nobody listening? Why does the ignorance continue?
> OpenSolaris engineering tends to route around damage. Make no mistake
I would call me an OpenSolaris engineer and I did not yet found a way to route
around the damage some people cause on my work.
> about it, people who spend most of their time looking for ways to
> obstruct others' work for personal reasons are damage. If you want to
Good point, please give me names.... who is responsible for the changes in Sun
tar?
> influence the state of archiving software in OpenSolaris, you'll have
> a lot more luck if you engage honestly and constructively. All your
> message here has done is put me and everyone else on notice that if we
> want to do anything to tar, we should avoid at all costs asking you to
> review our changes or otherwise participate. That's unfortunate for
> everyone, because you could probably help improve quality by finding
> bugs others might miss. But it's not worth the hassle, so you'll
> likely be bypassed. Surely that's not your intent?
I am really sorry to read this kind of agressions from you.
In the past you have been a very friendly person. Why did you change?
Why don't you help to prevent that people block other people's work?
I don't like to see that the developement based on deprecated methods
will continue at nauseum. The only way to escape from this is to start
discussions on how extensions should be done in order not to use bad methods
from the 1980s.
The right method is to start discussions with experts from the community if the
related knowledge is missing inside Sun. In former times, the tar related
knowledge was obviously present/used (see the addition of the -E option in 1998
using a reliminary version of the POSIX.1-2001 standard.) After POSIX.1-2001
has become s stanard, the expected cleanup has not been done (moving from a
"vendor unique" variant of the POSIX tar extension format to the official
POSIX tar extension format). Even worse: lately many new extensions have been
implemented using the deprecated POSIX.1-2001 method instead of the method of
today. Why was Sun _the_ first adopter for the POSIX.1-2001 tar extensions and
why has the related knowledge been lost since then?
Roland and I are just the people who see the problems that are caused by
missing structures for cooperation. I don't like to be called a bad guy just
because I put my finger into open wounds. We need real technical based
discussions and the cooperation of people with expert knowledge.
Presenting ARC cases to the community is too late. In special if discussions
on the masics are blocked. OpenSolaris will only work if the best idea wins and
if we are able to prevent adding mistakes to OpenSolaris while implementing
enhancements.
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
