-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christopher Faylor wrote: | 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. Why not make the vote proportional to the number of packages the maintainer maintains? I agree any ol' maintainer should not have as many votes as, say, you, but an SC might make things a bit too massive..
|>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. In that case, why not make the SC, but just five the SC members veto right whereas all package maintainers would still have the right to vote? In that case, you and Corinna would be permanent members of the SC and the package maintainers could nominate the five other members (two nominees per maintainer). The five members that get the most nominations become the members. If there's a tie, we vote.
| 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. Yes, but it also takes away community involvement, concentrating it on a few elected members.
<long-winded_idea> Let me elaborate my idea a bit: the SC would consist of seven members, all package maintainers and/or cygwin (or cygwin-setup) developers. Two members - cgf and Corinna - have a permanent seat on the SC. The other five members have a six-month (or perhaps 12-month) term renewable ad infinitum.
All package maintainers get to vote on ITPs. The number of votes they carry is equal to the number of packages they maintain. Package admission requires at least 50% of the total votes (i.e. if there are 100 packages in the distro, 50 votes are required for a new packages to be admitted, but those 50 votes could come from only three people).
To avoid one person getting a decisive positive vote, the 50% of votes must come from at least three different package maintainers.
The SC members all get a veto right and may prioritize certain packages - - i.e. they may emit an ITP request ("this would be a nice addition to the Cygwin distro - maintainer wanted"). People that are not in the SC don't have the right to emit ITP requests.
An ITP that is a response to an ITP request is exempt of voting. This gives the SC members positive power as well as the negative (veto) power they already have. It is up to the SC members to discuss ITP requests amongst themselves (on a dedicated cygwin-sc list, perhaps?)
The SC members will also have the power to ban a package from the distro when it is already in the distro - either because the maintainer is MIA, the package has no real business being in the distro, or any other reason that is justifiable. Again, this is subject to discussion within the SC itself.
ITPRs are emitted to cygwin@; ITPs to [EMAIL PROTECTED] </long-winded_idea>
[snipped package-in-linux-distro, setup-redesign]
rlc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAbEFsU1nODpimgXsRAtSaAJ47nDnkeOMsjZMSq2cFzqg+y7AvEACgs9tH gEzBIlmLjzKKgpvGyNt9Muo= =lnTF -----END PGP SIGNATURE-----