Re: An irritated cygwin newbie

["Jon M. Taylor" <taylorj@gaia.ecs.csus.edu>]

On Wed, 18 Aug 1999, Chris Faylor wrote:

> I don't have much to say about this but there are a few of points:
> 
> 1) Cygnus doesn't directly fund Cygwin development as an open source
>    project.  Cygwin was developed here to allow building of our GNUpro
>    toolset.  Much of the work done on the project is volunteered by
>    two people.

	Oh.  That explains a lot.

> 2) The actual Win32 group at Cygnus has gone from three engineers
>    to one engineer since B20.1.

	That also explains a lot.  Why do you not ask for help in big bright
red letters (well, you know what I mean) on the web page, then?  How are
people supposed to know you _need_ help?  I've passed up Cygwin several times
when looking around for a needy open-source projects to spend some time
helping, because the FAQ and web pages make it look like a large core team is
already present.

	I have relevant work experience, too - I worked at NEC for a while
last year on a project which was creating a system API emulation tool which
was quite similar to Cygwin.  We were porting a non-POSIX API for an old
proprietary Japanese-market Unix (UX4800) to HP-UX.  It was backwards 
from Cygwin (porting non-POSIX to POSIX), but most of core API bridging 
issues should be quite similar....
 
> 3) AFAIK, EGCS provides only sources for *you* to compile.  Cygwin provides
>    binaries which are installed via InstallShield.  It's a minor matter,
>    but I'd be happy to release B21 as a source-code only distribution.
>    It would simplify things greatly.  I doubt that that would be acceptable
>    to many people.

	Probably not.  Cygwin is too big.  But I do not understand what the 
problem is with the binary distributions.  Is there lack of suitable 
hardware or something?  

> 4) EGCS has a lot of high quality contributors.  Cygwin has (not counting
>    DJ or me) two or three.  Most of the users of Cygwin are people like
>    you -- they want tools and they want them good and hard.  

	Don't misunderstand me.  I do not expect everything to work golden. 
I have been doing open-source coding for too many years now to expect that,
especially from a project as huge and intricate as Cygwin.  What I _do_
expect is that the basic documentation (FAQs, install instructions, feature
lists) is more or less up to date and factually correct.  I believe that such
things are more important to get right first than a few extra features or
even bugfixes.

	The GGI project went through a phase a few years ago when our FAQs
were horribly out of date, our web pages were not getting updated, release
schedules were erratic, and informal third-party patches and workarounds were
the order of the day.  And the result of all this mess was that we started
seeing messages on our mailing list much like the one I wrote that started
this thread - people who had wasted lots of time and endured massive
frustration due to the mess.  It took an outsider who really wanted to 
use LibGGI but could not deal with the chaos to speak up on the mailing 
list to wake us up.

	I see this project heading down the same path, and I wanted to say
something about it.  One observation that was made to the GGI people back in
the "dark days" that I think should be burned into the forheads of every
open-source project manager is this: open source projects live and die by
their ability to attract and hold the interest of skilled coders, and first
impressions count for a lot in this regard.  Some people will instantly latch
on to your particular project because it is exactly what they want to code,
but more often you see people who are good coders and want to do "something
cool".  These folks will be put off by chaos, and will wander off to end up
contributing lots of coding hours to another project whose barriers to entry
are not so painful to get around.

	GGI lost a lot of skilled coders during our "dark days" because they
could not deal with the chaos.  The difference in overall project health
since we cleaned up our act has been nothing short of stunning.  But what it
took was all of us "core coders" putting our pet coding projects down and
focusing on a massive spring cleaning.  The web pages got overhauled, the FAQ
was rewritten, manpages were updated, build systems and directory structures
and the configuration system were overhauled, everything that could be
automated was, and a comprehensive overview of all outstanding bugs was drawn
up and the bugs were methodically squashed.  We also chose to be far more
rigorous about defining alpha/beta/release cycles and sticking to them.

	I won't lie.  It *really* sucked to have to put our noses to the
grindstone like that and spend an extended period of time doing boring,
trivial gruntwork.  But boy was it worth it in the end, and now that we are
used to it, it isn't nearly so bad.  I just want to strongly encourage the
Cygwin team to consider holding their own spring cleaning.  I would be more
than willing to lend a hand.  I cannot promise to become a core developer -
GGI is still my first priority right now.  However, I can fix bugs and work
on boring crap like webpages, mailing lists, FAQs build systems and whatnot,
which is really what needs to be done.

	But I will not volunteer my time for this unless I see a clear
commitment from the people in charge that A) my ideas will be listened to
with an open mind, B) I will get help from other "core coders" on cleanup
work that is deemed by group consensus to be needed, and C) a concerted
effort will be made to stabilize the current CVS tree and get a solid b21 out
the door (pulling stuff that is too unstable to fix reasonable quickly from
CVS if necessary).  If people will agree to this, I will be happy to help 
out.

>    There are
>    probably scores of suggestions every week for how the project could
>    be improved.  There are very few offers to volunteer to help (although
>    I have recently received a few offers of help for which I am *very*
>    grateful).

	You just received another one.

> 5) Given that Cygwin is an emulation layer I can't imagine why you would
>    consider porting GGI using it.  There will be inavoidable slowdowns
>    which I would think would be unacceptable given the nature of what
>    it is doing.

	As long as the core rendering functionality can call out directly to
the DirectX DLLs, which appears to be possible, the overhead of the Cygwin
API calls should not be too bad.  A graphics API such as LibGGI is, by its
nature (speed is everything) designed to structure execution flow along
clearly defined code paths and to minimize system API calls at all times, 
regardless of the particulars of the native environment.  LibGGI is 
already ported to ~25 very different rendering targets and many different 
versions of Unix.  We have been dealing with this issue for some time 
now.

	This is not to say that (for example) a slow select() wouldn't have a
major impact on LibGGI performance.  But at least we'd be able to clearly see
the potential optimization hotspots, both in LibGGI and in Cygwin, and that
never hurts.  And the nice thing about Cygwin is that, if some or all of the
LibGGI code turns out to just plain require a native port, only those parts
need be ported and the rest can be left alone.  And even if I should end up
with a 100% native win32 port for some reason, Cygwin will have been a
valuable stepping-stone on the way there.  I have many reasons to want to use
Cygwin, but LibGGI is far too complex a system to port unless I can get a
clear sense of what works and what doesn't.

> I am grateful that you took the time to outline the problems that you
> see with the project.  I wish we had more time to devote to getting a
> release out.

	You have as much time as you devote to any other aspect of Cygwin. 
It is up to you how you choose to make use of that time.  The same goes for
everyone else in the Cygwin core team.  Every time you sit down to a pleasant
little hack-session on your pet codebase, think long and hard about whether
what you are are doing is *really* more important than fixing bugs or
updating a portion of the FAQ.
 
> Maybe if I stopped reading this mailing list, that would help a little...

	I think that would be the exact opposite of what you should do.  All
the whining on the list (even my posts |->) shows you where the weak spots
are.  If you are finding yourself growing annoyed by people repeating the
same questions over and over again, that should be a rather large red flag to
you that longstanding problems are not being addressed.  I have an informal
personal policy of not letting a problem report come up more than three times
on the GGI mailing list before I try to fix it (if it is in my area of
responsibility) or bother the person whose area of responsibility it is.

	If the problem cannot be fixed, either it is fundamental, in which
case a meeting of the minds between developers is _required_ to straighten
things out, or it must be fixed but cannot be immediately in which case we
fix everything about it than can be fixed, clearly define and document the
rest, and set a schedule/milestone/plan/whatever for fixing it.  My point is
that, whatever is done, it is done consistently and major developers who do
not cooperate in keeping their corner of the project clean in this manner get
taken to task for it.

	Linux is a successful open-source project primarily because Linus
enforces QA standards and alpha/beta schedules.  To the extent that he has
not in the past, problems have always cropped up.  The v2.0 fiasco is a
shining example of this, and we all learned from that unpleasant experience. 
That is why Linus is trying to get 2.4 out the door by the end of this year. 
As the major truly outstanding example of how to do software engineering
(with binary releases, even, though done by others) in a very large and
complex open-source development project, Cygwin could certainly do worse than
to emulate Linus' methodology.

	Sorry for the rather pedantic and lecturing tone of this mail (I just
reread what I wrote), but I have seen this exact same problem do a lot of
damage to a lot of open-source projects over the years and I really would
hate to see it happen to Cygwin (any more than the mailing list shows that it
already HAS happened).  Cygwin is a wonderful concept and I can see that a
lot of very talented coders hang out here, but all the coding talent in the
world doesn't help if people can't use the results in a reasonably stable,
cohesive system.  I have to be honest about the problem areas that I see. 
Take what I say however you wish to.

Jon
 
---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com