Mail Archives: cygwin-developers/2001/09/30/20:47:44
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
- Raw text -