Votings
The EPEL Steering Committee often decides stuff in the regular IRC meetings of the EPEL SIG. But not all SIG and steering committee members can attend each meeting. So for decisions that are controversial or can't wait until the next meeting we'll use this page to collect the opinions and ideas.
Please prepare votings by
- adding them to this page, including details like
- a short statement what the vote is about
- the available options including their pros and cons; please try to be fair to each side, even if you prefer a option
- announcing the vote to the mailing list so people can discuss the options -- or yell at you if you missed pros and cons ;-)
- if needed: improve the voting description and send it to the list again if bigger changes were done
- wait a bit to give people a chance to discuss stuff before the actually voting starts -- normally at least three days. This gives non-steering committee members a chance to express their opinions and get heard before the voting starts
- votings should have a target date
Open votings
Note
Completed votings
200705 -- Elect a chair
In recent (during April/May 2006) EPEL SIG Meeting it was decided to have one person to act as chairmen for the EPEL Steering Committee. During the discussions both stahnma and knurd (formally known as thl) were nominated for that position and showed willingness to act as chairmen; there were no other (self-)nominations for that job.
When the actual vote came closer stahnma suggested to make knurd become the chairmen. knurd suggested to make stahnma kind of "vice-president", so there is one that will run the meetings or other stuff in case knurd is away. That is the proposed scheme this vote is about.
Site notes: The chairmen will get the position for the same timeframe as the steering committee has a mandate; e.g until end of September. But we can always "fire" the chairmen at any point if we like to.
Link to voting announced and discussion on mailing list: [not yet]
Voting period: 20070506 UTC 12:00 until 20070508 UTC 11:59
Voting Table -- please vote as "+1" if you support the proposed scheme, "-1" if you don't; you of course can also "abstain" or don't vote at all:
| dgilmore | nirik | mmcgrath | quaid | stahnma | thimm | knurd | outcome |
| +1 | +1 | +1 | +1 | +1 | - (what happened to defining what the "president" is allowed to do? ...) |
+1 |
Vetoing fedora-usermgmt until FPC makes a decision
Voting topic: Packages should not use fedora-usermgmt or other non-standard useradd replacements.
Background: Large thread starting at https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, also many threads on various non-epel lists, too many to list here.
Notes:
- A partial summary of arguments taken from a thread on fedora-maintainers:
1) Doesn't work in any other distro other than fedora 2) Only solves a small problem for a few packages since not all packages use it 3) Its proprietary. 4) Very few people use it 5) Its been controversial ever since its inception (otherwise it'd be mandatory by now) 6) Most sysadmins solve this problem on their own using well defined, tested tools 7) Its author doesn't seem to want to send it upstream to shadow-utils for reasons unknown 8) It hasn't gained any other foothold besides fedora 9) Its use isn't easy. Just in the last two days this thread and the EPEL thread have found people using it incorrectly or having it create UID's in an unpredictable fashion, and these are smart people.
- The author of this tool claim it won't work on RHEL: https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00126.html
- Author/packager of shadow-utils doesn't want it
Link to voting announcement: https://www.redhat.com/archives/epel-devel-list/2007-April/msg00006.html
Voting period: until 20070410 UTC 23:59
Voting Table (please vote as "+", "-" or "0"):
| dgilmore | mmcgrath | nirik | stahnma | thimm | thl | quaid | outcome (+:-:0:no vote) |
| - | + | - | 0 | + | - | 0 | 2:3:2:0 vote does not pass |
Introduction of a repotag
Voting topic: Should EPEL carry a repotag? If yes, the technical details will be delegated to the Packaging Committee.
Background: Last month's discussions under https://www.redhat.com/archives/epel-devel-list/2007-March/msg00276.html, https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html, https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html
Notes:
- This is a political decision to play nice with other 3rd party repos for RHEL.
- A possible implementation is to extend %{?dist} to include the repotag. Since EPEL is targeting building software out of the former Fedora Extras pool of software which at this point in time uses %{?dist} in 2989 of 3049 (98%) it does indeed already have a disttag everywhere but the epel-release package. So that seems the least intrusive and fastest way to achieve this.
Link to voting announcement: https://www.redhat.com/archives/epel-devel-list/2007-April/msg00005.html
Voting period: until 20070410 UTC 23:59
Voting Table (please vote as "+", "-" or "0"):
| dgilmore | mmcgrath | nirik | stahnma | thimm | thl | quaid | outcome (+:-:0:no vote) |
| - | - | - | + | + | - | 0 | 2:4:1:0 vote does not pass |
Rebuild of EPEL5
Background: The packages currently in EPEL5 got build against RHEL5beta1; the plan is to rebuild them against RHEL5. The question is: how?
Options:
1. Tell users to manually rebuild their stuff; for those packages that didn't get rebuild: Use a script that adds a ".1" to the Release of each spec file, commit the changes, tag, build
2. Simply delete the current repo and rebuild all packages
Pros and cons:
- With "1" ENVR stays unique, with "2" it doesn't; therefore in the latter case different packages with the same ENVR are in the wild (the new ones in the repo, the older ones on people that have them installed already), which can lead to confusing situations:
- bug reports: user still has the old package installed that has a bug while packager fails to reproduce as he uses the new one
- debuginfo packages from the new packages don't work for the older ones
- Note: the repo is still not officially annouced, and further rebuild/remove/restructure actions will probably be necessary; nevertheless people installed packages from the repo already
- With "1" can (if they want) make sure the build order is correct, the scripts used in "2" do not
- With "2" Specs stay in sync between different Fedora branches, which isn't the case with "1"
- With "2" and random build ordering the BR will be satisfied, but by the old packages that had been built against the beta release. In order to comb that away you need at least *a second rebuild* to ensure that EPEL packages have really never seen directly or indirectly the beta RHEL release. See also the CentOS/Scientific Linux build strategy that explains the pitfalls.
Link to voting announced and discussion on mailing list: not yet
Voting period: 20070409 UTC 0:01 until 20070410 UTC 23:59
Voting Table (please vote as "1", "2" or "abstains"):
| dgilmore | nirik | mmcgrath | quaid | stahnma | thimm | thl | outcome (1:2:0:no vote) |
| 2 | 2 | no vote | 0 | 2 | 2 | 1 | 1:4:1:1 option 2 passes
|