This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

On forming a SC [was Re: ITP moratorium still in effect?]


cgf wrote:

I'd like to explore new methods for getting packages into the
distribution, however.

Possibly we need a gdb packages steering committee which decides on
these things.  It could have rules like "a package needs a simple
majority vote to be a candidate for inclusion".  I'd envision seven
people on the committee.  I have names in mind but the only two
definites are really Corinna and me, both of whom would also have veto
power.

I'd also like to see a formal justification for why a package should be
included, remembering that we have a "software" web page at cygwin.com
which can be used to advertise packages that aren't quite up to snuff
for the cygwin release.  I think we have accepted a couple of packages here
which really only deserve to be advertised on the web site.
Chris,

I'd really like to object to this SC idea, as most of us *have* exercised restraint while a select few have not. Why should the responsible maintainers be punished for someone's binge ITP'ing? I think we should keep it the way it is, perhaps with a little more of you laying the smack-down on anyone who is abusing it. I would respect a veto from you, Corinna, or Chuck, but the voting should still be left to the existing maintainers. After seeing what a steering committee has done to gcc, I'd be very hesitant to subject Cygwin to one. Please don't turn Cygwin decisions into political ones.

Here's one idea to limit the binge ITP's:
No more than 1 ITP per month unless approved by either you or Corinna.

Another approach might be to ask: "Do the Linux vendors support it?". Obviously this won't apply to strictly-windows applications. However, it is useful in that we are attempting to provide a unix/linux-like environment for Windows. If we are going to use any benchmark, this should be it.

I'll end with some personal observations and opinions. I've been a RHL user since the 3.0.3 days, and I've seen the distro go from a small collection of packages to many hundreds of packages. Before that, I remember a time when an entire Slackware distribution fit on 20 floppies. Thus, I perceive our problems as being "growing pains". I think understanding how the linux vendors handled these growing pains would be fruitful in how we approach this problem. I know some might not want to hear it, but if setup.exe can't handle the current load or scale in a sane manner, perhaps the problem lies with setup.exe itself? Look, setup.exe has served its purpose well, but now Windows comes with a feature-rich installer API. The last time I checked, this API is available for all versions of Windows since 95. Didn't someone broach the subject of possibly looking into NSIS installer (which, if I'm not mistaken, is a front-end for this API)? Aside from being more aesthetically pleasing, there are some features NSIS has which are quite nice and would mesh well with some of the extended needs now handled by post-install scripts. Choice is what it comes down to, and IMHO it should be the installer who needs to responsible for selecting the packages which best fit his/her needs. I'm sick and tired of seeing things being "dumbed" down for the benefit of the clueless at the expense of the power-user, and I know I'm not alone.

Cheers,
Nicholas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]