"Garrett D'Amore" <gdamore at Sun.COM> wrote:
> Joerg,
>
> I think we have a few serious disconnects. I would like to point out
> what I think are some of the philosophical differences, as food for
> thought. I have a question for you at the end of this, so if you can
> take some time to read it all, I'd be appreciative.
My impression is that the main problem in the discussions are that I am
following the same rules (or at least similar rules) as people at Sun so.
If discussions are done at same eye level, this is not a problem.
If one side tries to dominate the other side, this may create problems.
> 1) First off, historical lessons from star, et. all may be interesting
> for star, but you need to understand that star history != Solaris
> history. Most of us here simply don't care about "precedent" set by
> something that the vast majority of our users have never seen or been
> exposed to. At least not for precedent's own sake.
I thought that Sun was interested in long term interface stability.
Is this no longer true?
> 2) Furthermore, choices that are good for a portable star may not be
> good for a bundled archiver that is considered a core part of the OS. I
> know this point is hard to accept, but really it is true. (For a purely
I know of no decision for star (done in the star project) that was not good
for OpenSolaris. If you believe otherwise, you would need to prove your claim.
> 3) Integration into OpenSolaris (well at least ON) necessarily means
> that you have to allow for other parties to maintain the code. If a
> customer with a multi-million dollar contract asks for a fix, then Sun
> engineers are going to have to come up with a fix, even if you don't
> agree. (You have the option of trying to convince C-Team via an RTI
> advocate or code review that this hypothetical "fix" is wrong, but you
> do not have veto power.) I had to yield up the same level of control
If Sun engineers believe that there is a need for a fix and if they did create
a patch, they are either able to convince me or the patch is wrong. What
benefit do you see from integrating a wrong patch?
As mentioned by Roy Fielding and me some time ago, the more someone helps
with the development in a OSS project, the more credits he gets when the
integration of new code has to be discussed. If Sun engineers help with the
development, they will get credits for future proposals, if they don't there
is a higher probability that a supposed fix is not done right anyway.
OpenSolaris benefits from OSS and gets a better tar implementation. OSS works
best if there is collaboration and if fragmentation/forks is avoided.
You did just tell me that you like to fragment/fork star. Is this really
your intention?
Code quality over a long time can only be granted if a limited number of people
accompany the project for a long time, if there are no quick and dirty hacks
and if things are well planned. If you don't believe me, please compare star
with GNU tar:
- Star has been designed and maintained by me during the past 26 years
and the result is code that has been rewritten several times and that
still offers a clean interface (with the star(1) CLI definitions).
Similar claims can be made for the code written fro sevral projects
by David Korn and Glenn Fowler.
- GNU tar started as PD-tar/SUG-tar 22 years ago. After it has been
renamed to GNU tar 19 years ago, many authors did add code. Most
problems in the current GNU tar source are still a result from the
"too many cooks" problem between 1989 and 1992 and from fact that
in the late 1990s maintainers abandonned the project, caused by
differences with a dictating non-maintainer (RMS). An interesting fact
is that GNU tar has about the same code size as star but offers
roughly half of the features of star only.
If at Sun's side there is one (or only a few) person who works on star, I am
sure this person will do things right and we will have no problems with a
development/maintanance that is targeted to the benefit of everyone and not
driven by short term wishes.
It seems that you need not only a milti-millon dollar contract but also such
a customer that asks for a fix many times. The problems you might see are
either problems that do not exist (as the customer did not yet ask many times
for a fix) or could be worked around with a patch that is clearly marked as
volatile and unstable. This gives time to device whether a "needed" fix is
really needed and correct or whether the problem needs to be handled in a
different way to do it right.
Finally: you cannot develop portable code inside a non-portable build system.
As discussed with the ksh93 case earlier, you cannot benefit from a portable
evolving project if you create a non-portable fork from a code snapshot. The
star code depends on my portability framework and if you like to benefit from
future enhancements, you need to take the whole ecosystem. Similar as with the
ksh93 project, you may create a set of Makefiles for the non-portable
buildsystem used to compile ON, but the project development needs to be done
in the original development environment.
> when I integrated afe/mxfe. Roland and Korn had to do the same for
> ksh93. So did Murayama with sfe. Maintaining a hard line dictatorship
I cannot remember any mail in the ksh93 case that proves your claim.
If Sun did make an agreement with David Korn, please send evidence for your
claim. For your help, I wrote down what I have in mind from the ksh93
discussions in the paragraph above and as I remember that there was nearly
complete congruence with my interests, I would be surprized if you find
different arrangements for ksh93.
...
> 5) While your Makefile/autoconfigure system may be the most excellent
> solution on the planet, the fact of the matter is that it is used by
> very few products (only the ones you authored, I believe -- feel free to
> correct me if I'm wrong). Converting all of ON (which is the only
It is used by some people and companies who decided to use it for their
projects.
If OpenSolaris likes to participate in the advantages from star, Sun cannot
try to dictate the development. There is a way to create a symbiosis of
OpenSolaris and star, the keyword is collaboration.
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
