>I am more and more shocked that such trivial items need to be debated
>at all. I am observing the ksh93 integration project nearly since the
>beginning and I have to question whether or not really all the
>bureaucracy is needed. I think Sun and the Open Solaris team should
>discuss options to streamline the integration process for all new
>projects and the bureaucracy needed during project evolution.
>The current process has become unbearable.
Are you part of the project team?
Or are you speaking for the project team?
Inside Sun we do get work done and we are faced with the same
bureaucracy.
I feel that these are valid architectural concerns; why do we need such
discussions? It's because when we revisit them later we know why they
were taken. It may seem cumbersome, but a lot of goodness comes out of
it (such as the disappearance of Solaris libcmd)
In the particular case of /etc/ksh.kshrc, we have several reasons for these
discussions:
- we introduce a file which is always read by ksh
- nice for system administrators, so this is good
- is it a pathname specific to Solaris or is it common?
- this file changes the default editing setting to gmacs, but
raises valid questions like:
- does this override $EDITOR or $VISUAL?
- does it override user's $ENV or ~/.profile or ~/.kshrc settings?
- is this a sensible default (clearly there's a disagreement
some (including me) think so, others such as jek3 do not;
- is it a sensible way to implement the default?
- is it how the default is implemented elsewhere?
- since this file is supposed to be editable by the administrator
what is the proposed patch/upgrade policy?
(for /etc/profile we use a class action edit script;
for /etc/.login, we just deliver the new file as /etc/.login.new)
Are these unreasonable questions?
Casper
