Mail Archives: cygwin/2002/04/23/21:48:58
> That works so long as the users come to that site to install and that site
> for support of the install. The current Cygwin policy is to offer email
> "support" for software it distributes. It's impractical to do otherwise.
> Also, the hope is that people who want to add features to anything Cygwin
> offers will do so in the context of the existing facilities. In this case,
> the desire is that people will enhance setup vs making some home-grown thing.
> This list would obviously entertain questions on install issues from the
> Cygwin distributed setup, no matter what functionality it has. So the
> policy that you see as being not liberal enough is one that merely attempts
> to keep the group focused both in a software development sense and in a
> support sense. It doesn't exclude functionality. It just seeks to add it
> in the framework that exists already. I hope that makes some sense to you.
>
Sure. I don't have a problem with the list policy. If somebody
got one of my products, hacked or misused it, and then tried to
get me to fix 'bugs', I wouldn't be too friendly. That's why I
thought a separate list for unsupported uses might be in order. I
didn't intend to criticize.
The reasons I didn't contribute what I'd done back to cygwin are
pretty clear if you've read the thing: It's a butt ugly hack,
and it's not really general. It does exactly what I need, but I
suspect that most people don't need that. Actually, there's a
third reason, which is that when I use this hack, I install a
great deal of non-cygwin software that I have no right to
distribute or contribute, so even if somebody did put similar
functionality into setup.exe, I would probably have to continue
to do an ugly hack on my own.
--
Got freedom? Vote Libertarian: http://www.lp.org
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -