Umpf... part of the problem are exactly these "fixes". Originally the
Many of them are fixes for problems that were identified over the
years. Some of them might have been for standards, most of them I
suspect were due to customers escalating bugs against the shell. Since
Sun's ksh88 had long ago "forked" from its root, fixing these in this
manner was a perfectly reasonable thing to do.
And your comments make me even worry more (or short: You've introduced a
new monster in my nightmares...) since this kind of argumentation wasn't
enougth to prevent the old /usr/bin/ksh falling into pieces.
As Danek pointed out in a previous reply, almost all of the things that
took place with ksh88 in Solaris predate "ksh93" being made available
as open source, the whole open-source OS movement or even OpenSolaris
itself existing. I understand and appreciate your concern, but I
wouldn't draw too many conclusions about the present based on that part
of the Solaris past.
Why was OpenSSH then fork()'ed in Solaris (OkOk, maybe a bad example
since AFAIK it involved some rampage with SSH upstream) ? Why did the
old ksh88 diverged from the upstream sources ? What about the status of
Motif and CDE in Solaris ? There are many examples in Solaris where it
went horribly wrong and I really don't feel pacified by the "...the SCM
and review will handle it for you..."-comments.
With respect to Sun's SSH, the best thing to do is ask the Security
Community ([EMAIL PROTECTED]) for the details. But
there were some issues with OpenSSH at the time which meant it did not
work well with some fundamental Solaris security frameworks such as
PAM. I believe the team involved were diligently to push their changes
upstream but for whatever reasons, it was not to be. The situation may
have changed at this point.
The other cases predate my arriving at Sun so I can't speak to them
although don't be surprised in the Motif and CDE cases if changes were
pushed upstream. As Danek pointed out, they aren't part of ON and in
any case, there was not the consensus then as there is today about the
need to keeping in sync upstream as much as possible.
I'd like to suggest that although everyone wants the latest features
coming down from ATT and there's certainly a benefit to getting some
early exposure in some cases by integrating changes often, what we
value in ON is a more deliberate, thought-out sets of changes. These
typically might be keyed to a new version or something. It's often
said that the ON gate (or really, any consolidation's trunk) is no
place for experimentation or debugging the project into existence.
I fully agree with that. The idea of the frequent updates is to get the
collection of fixes into OS/Net. All development is done in the upstream
sources, tested there and after testing results in "green light" we pull
the matching release into OS/Net. The only difference is that we're
doing lots of fixes+changes for Solaris right now and even more are
scheduled (like getting "chmod" synced) which will result in more
frequent updates.
It's a bit of an art as to how often to putback changes like this but
the most concise way I know of describing it can be found in the
OpenSolaris Development Process
http://opensolaris.org/os/community/on/os_dev_process/
where under the Quality Criteria summary there's the following
paragraph
The quality requirement of OpenSolaris is perhaps best stated
as "Production Ready All The Time". The idea is that at any
time, the release branch of a consolidation must be of
sufficient quality so that it can be used as-is as the basis of
a distribution or product. By using rigorous quality criteria,
the community can enforce that OpenSolaris avoids as much as
possible the Quality Death Spiral. This occurs when
contributors and users alike hear that a branch is broken and
as a result, they avoid incorporating the most recent changes
into their own project area or even stop using the branch
itself. This causes less real-world testing to take place,
additional bugs are not discovered and the quality of the
branch declines even further. When the Quality Death Spiral
occurs, it can be difficult to reverse and the time it takes to
recover can be very long.
Yes, mistakes might be made
at times but those can be remedied.
But how ? How do you undo the changes if you do not have access to the
SCM ?
The current release gatekeepers are the ones who have this ability
based on the judgement of the ON C-team. If a change is putback which
causes a severe enough of a regression in quality, performance,
compliance, etc, it can be "backed out".
dsc
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
