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

[Nicholas Wourms]

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