> 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/
