Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 30 Sep 2001 20:46:24 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Cc: info AT rlsystems DOT net
Subject: Re: baby steps vs overhaul
Message-ID: <20010930204624.C3722@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com, info AT rlsystems DOT net
References: <00e301c14a0a$3090f820$01000001 AT lifelesswks> <20010930202016 DOT B3722 AT redhat DOT com> <010701c14a10$96c0e280$01000001 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <010701c14a10$96c0e280$01000001@lifelesswks>
User-Agent: Mutt/1.3.21i

On Mon, Oct 01, 2001 at 10:32:44AM +1000, Robert Collins wrote:
>Ok, cc'ing Ronald. (will his posts get rejected?)

Yes, unless he subscribes.

As you know, subscription to cygwin-developers is limited on a by-approval
basis.

I recently changed the subscription notification message to indicate
that one should send email after getting the notification, answering
some specific questions wrt the desire to work on cygwin.  I used to
just send these messages "by hand" to anyone who tried to subscribe.

99% of the people who previously tried to subscribe were either confused
or indignant when I sent my message.  The majority wanted to subscribe
so that they could "send bugs to the developers".

So far I've seen a few subscription requests.  Ronald may have been one
of them.  I don't know.  So far, no one has yet followed the the
instructions in the confirmation message.

If he wants to subscribe, though, he just has to follow the instructions.

>----- Original Message -----
>From: "Christopher Faylor" <cgf AT redhat DOT com>
>To: <cygwin-patches AT cygwin DOT com>; <cygwin-apps AT cygwin DOT com>
>Sent: Monday, October 01, 2001 10:20 AM
>Subject: Re: baby steps vs overhaul
>
>
>>On Mon, Oct 01, 2001 at 09:46:55AM +1000, Robert Collins wrote: All
>>that is required is for someone to submit a patch for consideration.  I
>>certainly will consider a patch that advances an architectural goal but
>>I'm not going to accept something that breaks cygwin for any length of
>>time.
>
>Abso-bloody-lutely!.  I guess I didn't really make that clear.  Done
>right this approach _never_ breaks cygwin at all.  And if a mistake
>happens - which is what I meant by *hiccup* - there is only _one_ patch
>to roll-back.

Yes, you made it clear.  I was reinforcing your point with my booming
voice of authority.

>> I'd like to also be convinced that anyone submitting patches is going to
>> be around for the long haul.  I accepted, much against my better judgement,
>> patches from people who were going to add pthreads to cygwin and make it
>> thread safe.  As we all know, the patches were incomplete and the people
>> disappeared.  I'm not going to repeat that mistake again
>
>I presume this was the code I have replaced?

Yes.  I was essentially ordered to accept patches even though I *knew* what
the result would be.  It was difficult to communicate with the original
pthreads/threads contributors during the initial stage of their development
and then they just disappeared when bugs surfaced.

>> >2) Add the capability to manipulate the mount table with associated
>> >fshandlers. (this involves altering mount.exe as well.)
>>
>> I don't know why this would involve mount.  Except for one specific case
>> for the cygdrive stuff, mount just calls setmntent/getmntent/endmntent
>> to display information.  If we have to do something different from that
>> then, IMO, the model is wrong.
>
>Ok, here's the goal, I'm happy to hear of a different approach.
>$ mount -t devfs /dev
>and optionally
>$ mount -t win32 /usr/bin options=win32path=E:\\cygwin\\bin
>or in other words, just like linux.
>
>I really cannot see _any_ correct way way to achieve this without
>altering setmntent and therefore mount.exe. However, the linux API can
>provide the exact API interface to use. (This is what you told me to go
>and do for the UMSDOS stuff I was working on).
>http://sources.redhat.com/ml/cygwin-apps/2001-06/msg00104.html

You're right.  I was completely wrong.  That would obviously require
changes to mount.

>>However, your points are well taken.  Thank you for enumerating the
>>ways that an incremental approach to this design could be taken.
>
>My pleasure.  I'm always keen to avoid wasted work, and that is the
>risk when starting an architectural change (as opposed to simply adding
>a new fhandler for example).
>
>>I want to also point out the fact that Cygwin is a product that is used
>>and sold by Red Hat.  We can't afford (literally) to keep it in an
>>unstable state for too long.
>
>IMO it should never be unstable.  Thats the point of developing
>off-HEAD.

Again, I was just summarizing my position and hopefully putting to rest
the "we can make sweeping changes to the core of cygwin" argument.

cgf