Joerg Schilling wrote:
Well, there was a statement (from I believe it was Keith) that Sun was
going to work OSSing Teamware in 2005. I was waiting for the results on this.
If you read the links I posted, you'll see that this was in fact the
case, but that it never came to fruition.
From my information, Teamware was still in use by Sun in December 2006.
It is, but the migration process is well under way, and the discussions
are taking place on the public mailing lists hosted on opensolaris.org.
After a discussion started on SCM without an Teamware option, it was
obvious to me that the result for this "discussion" was no longer open
but predefined by Sun.
You keep repeating that, but it simply isn't true. Teamware was on the
initial list, but was discarded, along with several other candidates.
The decision to drop Teamware was made by the whole community, not just
Sun. This is all a matter of public record, for confirmation, read the
archives.
But I did already mention that we probably do not need Teamware and may use
an enhanced SCCS. Larry McVoy did tell me that he did develop Teamware
as a separate source because he did not like to enhance SCCS because he
believes the SCCS source is not extensible. I believe that SCCS could be
extended after some minor code cleanup (a noticable part of this cleanup
has been done by me already in January). Larry did implement the needed
functionality insice "bk" and I believe this should be done inside
sccs(1), admin(1) and get(1).
- Add libfind to sccs(1) to allow something like:
find . -path '*/SCCS/s.*' -exec get ... {} \;
- Add a new "release" tag similar to the "mr" tags
to the SCCS file headers. To allow tagging parts of a
tree to be part of a release snapshot.
- Add a new project-root understanding and a project-root
lock that allows to do things on the whole tree
- Use a hacked librmt (from star) to implement remote
operations via a ssh (and later web) tunnel.
In the end any piece of software can be modified to do anything, but the
modifiability (or not) of of SCCS wasn't the deciding issue. For
example, we currently rely heavily on the additional functionality that
Teamware layers on top of SCCS - SCCS on it's own is not a viable
option. There was a free and proper evaluation of the different
candidates, and the community chose Mercurial and Subversion. The fact
that you don't personally agree with the decision doesn't make it an
invalid decision.
This is not much work but it does not make sense to discuss _before_
SCCS is opensourced. The fact that the SCM discussion started before
OSSing SCCS makes it obvious to me that there was a Sun internal vote
against SCCS before the "discussion" went public.
If there was a Sun internal vote, I sure as hell didn't get to
participate - perhaps there's a Sun conspiracy against *me*? Al Hopper
has given a good explanation of what happened WRT the open sourcing of
Teamware, so I won't repeat it again here.
Accusations of underhand behaviour that aren't substantiated are not
helpful to the growth of the community.
Of course, that's just *my* opinion... ;-)
--
Alan Burlison
--
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
