Re: An article about the Cygnus tree

[msokolov@ivan.Harhan.ORG (Michael Sokolov)]

David Edelsohn <dje@watson.ibm.com> wrote:

> I find your "Introduction to the Cygnus Tree" to be riddled with
> incorrect statements.  I do not understand why you apparently made no
> attempt to investigate the facts before publicly releasing a thoroughly
> inaccurate document.

I *did* investigate most of the facts. I have been watching these facts unfold
for a while now, I've been saving all the important bits of information about
this stuff I've come across in the past (even though I didn't need them then),
and I've done some CVS repo archaelogy. I did miss a few fine points, but you
could have certainly been a little more polite in pointing them out.

> Cygnus, as a company, never has been the official FSF-appointed
> maintainer of *ANY* GNU Project package.

I didn't say that they were FSF-appointed maintainers. That is politics that
I prefer to stay out of. I was and am focusing on the *technical* aspect of the
transition. First there were GNU packages with all their "meat" at the top
directory level. The Cygnus tree had versions of them grafted under the top-
level configure script and Makefile. What was so remarkable about the
transition from FSF's gcc2 to EGCS/GCC, and the much earlier transition in
Binutils and GDB that I, perhaps incorrectly, referred to as Cygnus takeover,
is that the FSF packages with the "meat" at the top directory level *went away*
and the version of the program in the Cygnus tree became the master one, with
all subsequent EGCS or FSF tarballs being made from the Cygnus tree and
carrying top-level configure scripts and Makefiles telling curious code readers
about the rest of the tree.

Also when I say "Cygnus tree", I'm not picking on them as a company. (And yes,
I know that they are Red Hat now.) I call it the Cygnus tree for exactly the
same reason why the configure script at its top is universally known as Cygnus
configure and called this way by everyone, and why the Automake option enabling
special rules for this tree is named cygnus. In fact, I took the name Cygnus
tree from configure.texi, before I read that I didn't know how to call it.

And while I think this is stated clearly enough in the article itself, let me
repeat: the previous point (that I wasn't even sure what to call it) is the
essense of the problem that needs a solution: there is a sore lack of public
tutorial information on this animal. There is a home for the GNU project and
there are home pages for all GNU projects, and as a result, everyone knows what
they are and where to get them. But it's very hard to explain to a newcomer
what the Cygnus tree is. See below.

> Daily and weekly snapshots of
> the various packages (gcc, gas, gdb, and binutils) were available to all
> active developers prior to the public CVS repositories;

I know this, and I never said otherwise.

> The hosting of the gcc.gnu.org site by Cygnus/Red Hat is not a
> "dirty little secret".

When writing that, I assumed that everyone reading those words would understand
them as tongue-in-cheek. Your reaction shows that I was wrong. Sorry 'bout
that. That and all the language about "conspiracies" was intended to convey
that the lack of a home for the tree overall, as opposed to its individual
modules, makes it look like a conspiracy. *Of course* I know that everyone
working on this code is extremely devoted to free software and that there are
no conspiracies. I was pointing it out that there is a problem with not having
a home for the unified Cygnus tree and that it makes it look like a conspiracy.

> Whatever ax you have to grind [...]

I don't have any axes to grind, and I'm very sorry that you have so completely
misinterpreted my article. I really don't think I could have made any clearer:
in the article itself I have clearly stated more than once why I wrote it and
what I'm trying to achieve.

I think I have explained it as well as it could be in the article, so repeating
it here would be just wasting bandwidth, but let me repeat it very briefly. I
have projects that use the Cygnus tree instead of discrete releases from
ftp.gnu.org. These projects have found it unacceptable to build bfd and opcodes
twice and libiberty three times. I, being a developer and knowing the "secrets"
(tongue-in-cheek) which most developers know but which are not written down in
ASCII anywhere, have no problem with this and have found the compilation time
reduction and ease of development tracking very pleasant. But right now I'm in
the process of preparing a release, and this is where I hit a problem. It's
trivial to tell your users "this system uses GCC, Binutils, and GDB, go get
them". But it's infinitely harder to tell them that a system uses the Cygnus
tree, given that there is no home for it where people can learn what it is,
that there is no single repository to get it from, and that a lot people don't
even know that such a thing exists (been there myself).

First all I wanted to do was to explain the procedure for piecing together the
tree from the two repos. But before I even got there, I at least had to say
*what* does one need to build. I needed to refer to the Cygnus tree. It's
trivial to say "this system uses GCC" and point to its WWW page. But for the
Cygnus tree there isn't any. In Free Software when you need something that does
not exist, you create it. This is exactly what I did in writing my article. And
of course after having explained the horrible procedure for piecing together
the tree when the correct solution (repo unification) is obvious, it was only
proper to make a call for action to actually implement this correct solution.

> [...] before you start patting yourself on the back for getting
> things rolling.

I was never planning on doing that actually.

Anyway, I have checked in version 1.4 of cygnus-tree-intro with the language
changed so that hopefully fewer people will get offended by it and more people
will gain useful insight from it, which was its original intent. It is in
ivan.Harhan.ORG:/pub/embedded/cygnus-tree-intro.

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)