Mail Archives: cygwin/2008/06/20/15:54:52
On Fri, Jun 20, 2008 at 12:49:21PM -0400, Larry Hall (Cygwin) wrote:
> Mark J. Reed wrote:
>> On Fri, Jun 20, 2008 at 8:37 AM, Eric Blake wrote:
>>> [Please avoid http://cygwin.com/acronyms/#TOFU - don't top-post]
>>> [Please avoid feeding the spammers -
>>> http://cygwin.com/acronyms/#PCYMTNQREAIYR ]
>>Sorry, I need to stop using GMail Mobile to post to this list. It
>>leaves me no option about either of those.
>
>I assume you mean beyond doing this manually. I feel your pain.
>
>>>| Is there a ticketing/tracking system for Cygwin where one can submit
>>>| feature requests? I The mailing list archives are as good as
>>>anything else.
>>Not really, because they're full of all sorts of messages that are
>>neither defects or feature requests, and repeated requests don't get
>>collapsed into a single thread.
>
>I think we can all agree that there would be some value in such a
>system if it was well maintained and easy to use.
Actually, it already exists:
http://sourceware.org/bugzilla/enter_bug.cgi?product=cygwin .
But I don't know how often setup.exe developers check it.
I don't know what adding a bugzilla entry with an RFE for search inside
of setup.exe is going to accomplish given that no one is a programmer
and, if they are a programmer, they don't implicitly understand the
setup code base however.
>>>Read the archives. This has been repeatedly suggested, but no one has
>>>yet proposed how to solve the chicken-and-egg problem of how you get
>>>apt or yum first installed (how do you install cygwin1.dll with a
>>>program that depends on the existence of cygwin1.dll?).
>>
>>Why does the initial installation wizard have to be the same as the
>>post-installation package manager? Certainly the extra first-install
>>bits of setup.exe (e.g. "pick a mirror") are some of the more annoying
>>things about using it later on. If you take out most of the
>>flexibility from the initial setup, it doesn't need to have the same
>>capabilities as a full package manager; it can just give you the
>>default set of packages, or maybe let you pick from two or three canned
>>sets targeted at developers and/or heavy X users. You could probably
>>even use InstallShield or similar.
>
>Again, this has been discussed in the past.
And, observations about choosing a mirror being "annoying" don't really
help and likely illustrate some fundamental process misunderstanding.
What would you do if you didn't choose a mirror? Assume that the last
one you used was up to date?
Should we be spending a lot of time educating people about this so that
they can give ever-more-informed suggestions without ever stepping up to
help?
The thing that never seems to be understood in these merry-go-round
discussions is that very few of us are insightful geniuses who have
innovative new ideas for improving setup.exe. The suggestions are
by-and-large obvious. In general, the developers have all of these
ideas and more, if for no other reason, than they've been here longer
and have been thinking about the problem at some depth.
So, why isn't setup.exe better? It in't because we stubbornly don't
like to make changes. It is because no one has the time or inclination
to put man months of effort into introducing new functionality.
In projects which have a healthy number of developers, getting people to
do work is an issue of finding someone with an itch to scratch. In
projects with four or five developers and a big user base things move
more slowly or not at all. We tend to shy away (Cygwin 1.7 being a
notable exception) from making big changes because then we have to
support them and maybe even hear about all of the people who just loved
things the way they were and are sick of us changing things. So
we focus on fixing bugs.
Predictions of doom because suggestions aren't warmly received and vowed
to be acted upon miss several points. The project doesn't succeed
because Anissa-Random-User decides to grace us with a suggestion. It
succeeds because people find it useful.
A project really flourishes when there are enough developers to keep the
project running. Cygwin has that just barely. No amount of indignation
is going to change that or convince a small team of busy developers to
do your bidding.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -