On Sun, Mar 28, 2004 at 04:02:55PM -0500, Nicholas Wourms wrote: >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. > >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.
I guess we have differing views on how the steering committee affected gcc but this is really very different from the gcc (or gdb) steering committee. In general, I think they do a good job. However, just because I used a similar term to describe this doesn't mean that it will be exactly like gcc's steering committee. I'm coming to feel that their should be a higher bar for package entry into the release and don't think that any old package maintainer should get an equal vote in the process. >Here's one idea to limit the binge ITP's: >No more than 1 ITP per month unless approved by either you or Corinna. I can't speak for Corinna, but I would rather *not* have to be the bad guy or a single (double?) point of contact. I would rather have more community involvement. I'm already drowning in being the focal point for most cygwin bugs with help from only two other developers. I don't want to invent new things for me or Corinna to do, especially when there is no requirement for in-depth cygwin knowledge. Setting up a council or committee to approve or disprove apps means that the load is shared and there theoretically a consistent way for packages to be included. >Another approach might be to ask: "Do the Linux vendors support it?". That is exactly an idea that I was going to propose. I was waiting to see where the discussion was going first. I was going to use actually veto ac-archive on this basis but then noticed that when I typed: up2date ac-archive ac-archive got pulled into my fedora-based system. So vetoing ac-archive because for this reason wouldn't work. However, even with this rule, there is still a need for someone(s) to rule on the edge cases. >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? This was part of my motivation for asking if setup.exe development was stalled. I think that we are reaching a point where some innovation (and maybe a radical GUI redesign) is needed. >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)? Yes, someone did. I have no problem with moving to a new installer interface but, given the current level of development, I don't see who's going to do the work. If we don't have a volunteer available to do the work of adapting NSIS but we do have volunteers available to keep setup.exe working then it's really a moot point. >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. I've always felt like this, actually. The first version of the installer was just a command-line version. I don't think that the current setup.exe is dumbed down. It just isn't really feature-rich. cgf