On Fri, Aug 29, 2014 at 3:08 PM, Stephen John Smoogen <smooge@gmail.com> wrote:
  • EpSCO governance.
    • Lifetime of initial committee (9 months?)
This is fine for me.  Somewhere in the 6-12 month range seems reasonable.

    • Replacement of any exiting members (replacement by formal vote, etc).
Vote of existing committee members, or vote of the wider EPEL dev/user community?  I'm fine with having it done with a committee vote.
 
    • Size of committee (4 members? 5 members?)
I was in favor of 4 members when it was brought up in the last meeting.  However, it occurs to me that all of the people volunteered/nominated are RedHat employees (correct me if I'm wrong?).  So I'd prefer to have one more member -- a non-RH person.  This is in no way a comment on you all who I trust and believe want to do best by the community, but others may not see this the same way.

  • How many repos? (examples below)
    • epel,
      • epel-test
    • epel-rolling
      • epel-rolling-test ?
    • epel-edge ?
      • epel-edge-test ?

It seems like we need to discuss some current example packages (already started in this thread) before jumping into a "solution".  My gut says, the fewer repos, the better -- and "testing" repos for very fast repos may not be necessary/helpful.

  • Would packages in this be able to conflict with epel packages? Base packages?
From Jim's comment, overwriting base and/or "slow" EPEL packages may be required for at least the CentOS SIG use case.  I can see the need for this, but obviously some thought needs to be put into the approach to make it a) easy for people to use and b) not blow up people's systems that don't know better.
 

  • When would incompatible changes be allowed in each branch?
  • Different guidelines for specs/packages per branch?
  • When would a package be expired or removed?
All good points that should be discussed as the branch discussion moves forward -- I don't have any specific comments at the moment.

 
  • Currently packages require of 2 weeks in EPEL-testing before promotion to EPEL.
    • Can this be changed to 1 week?
    • What Constant Integration would be needed to give auto-karma?
Self-serving +1 vote for changing this to 1 week.  And I love the idea of using CI to do some "basic" package tests once something is pushed to "testing".
 
-Jeff