Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Wed, 18 Aug 1999 18:40:36 -0700 (PDT) From: "Jon M. Taylor" To: Chris Faylor cc: cygwin AT sourceware DOT cygnus DOT com Subject: Re: An irritated cygwin newbie In-Reply-To: <19990818194202.A3276@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 AT sourceware DOT cygnus DOT com