Josh Hurst wrote:
Why is it required to remove .so and lint libraries? You don't do that
for X11 even when the API is not public.

Please see the architectural policy on libraries at
http://www.opensolaris.org/os/community/arc/policies/libraries/

In particular, note W2 and W3 in that document.

If the ksh93 Project Team chooses to specify some of the interfaces
in their project as public or private, that is their choice.  You may
argue with them about the validity of their choice, but, in the end,
it is theirs.  Once they choose what interfaces and stability levels
to export, policies like the above tell them the consequences of their
choices.

In this specific case, IIRC, the project team is starting off with
a restricted set of public interfaces and a constrained set of stability
levels in order to not paint themselves into a corner WRT their near-
future evolutionary plans.  They plan on increasing the number and
stability of their exported interfaces once they get their first set
of integrations completed.

Something about "done being better than perfect"....

Why is is necessary to demand the removal of diff files from the
source tree even after the project team has begged Sun to leave them
in?

IIRC, this was a conversation between people who would have to deal
with these artifacts, a (not quite completed) discussion about how
to best do this without replicating stale information in a VCS; I
certainly don't recall seeing anything on Jonathan's blog, or on
any of the Sun Press Releases about such an official Sun demand...
Or are you confusing Community members who are also Sun Employees
with Sun, the mega-death-dealing evil corporation?

Why are 3 Arc cases required for one shell?

Several answers come to mind:

o Because the shell in question has, as goals, the replacement of
one of the core pieces of the system and the introduction of new
command invocation mechanisms (libcmd) that, if not thought through,
could negatively impact the whole system.

o Because this community uses ARC cases as the means to record
architectural changes to our code.  It is the process we use so
that we are proactive, doing things by intent, rather than being
reactive and being forced to deal with chaotic, unforeseen problems.

Why does it take that long to get a simple shell added to Solaris?

If it was simply a case of adding a shell (and nothing more),
it shouldn't.  IIRC, the cases that added zsh, tcsh and bash
were all fasttracks; the case for upgrading zsh from 4.1.1 to
4.2.0 was a self-review with automatic approval.  The difference
(as noted above) was the INTENT - none of these intended to be
anything more than a bolt-on alternate shell.

Linux+Gnome is much faster than Solaris+JDS

I'd look to bugs in GNOME/gtk first, though this certainly
could be Sun's fault for not finding and fixing every bug
there is in the FOSS code that they import into JDS.  Where
a "mindless rule" comes into play here, though, is beyond me.

JDS doesn't grok Gnome session files from Linux.

Blame this directly on GNOME - their config file formats have
been wildly unstable between versions, making it difficult to
reuse them across versions.  IMHO, GNOME was not designed to work
in an enterprise-style shared home directory environment, so
it is not surprising that issues like this come up.  Are they
frustrating? hell yes.  avoidable? could have been.  All Sun's
fault or mindless rules? nope.


  -John

_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to