From:	cgf AT bbc DOT com (Christopher Faylor)
Subject:	Re: cygwin32-developers problems?
10 Mar 1998 10:23:46 -0800 :
Message-ID:	<EpM1wq.34A.cygnus.cygwin32.developers@bbc.com>
References:	<199803100128 DOT UAA08056 AT hardy DOT bbc DOT com>
Reply-To:	cgf AT bbc DOT com
To:	cygwin32-developers AT cygnus DOT com

In article <199803100309 DOT TAA05291 AT rtl DOT cygnus DOT com>,
Geoffrey Noer  <noer AT cygnus DOT com> wrote:
>Christopher Faylor wrote:
>[...]
>> The main thing I remember typing was that you could make a case that
>> Linus had it easy compared to Cygwin.  If something isn't working quite
>> right in the kernel he can implement it.  If he needs a nifty new
>> synchronization primitive he can just code one into linux.
>
>We do have complete control over our Cygwin kernel so I don't think
>our job is particularly harder but it is certainly as hard.  We have
>access to a large enough variety of locking primitives that I don't
>think we need to write any.  :-)

One other suggestion I made in my lost email was to break out the cygwin
development from the tools development.  Actually, I think that Geoffrey
has mentioned this before.

You could modify the installation procedure so that there were three (or
more?) packages.  A "base" package, a "developers" package, a "users" package.
This is nearly what is done now, but you could also allow click and choose
installation of specific packages.

If the three packages were always maintained separately then, maybe, they
could also be released independently of each other.  That would mean that
when there was a problem with something like 'sh' as we've seen in B19,
we could just release a new version of the "base" package and leave the
other two alone...

This doesn't speak to the issue of fixing up CYGWINB19, really, but it
could remove some distractions.
-- 
http://www.bbc.com/	cgf AT bbc DOT com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."

- Raw text -