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

Thu Apr 1 16:37:00 GMT 2004

-----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 cygwin-apps@.
</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-----