EPEL epel7 planning and processes

[Kevin Fenzi]

Greetings. 

Several folks have been asking about epel7 and we should get the ball
rolling now that there is a public rhel7 beta. 

I'd like to propose a similar plan to the one we used for epel6, which
the possible exception of branching method. 

For epel6 we asked maintainers who didn't want to branch their packages
from epel5 into epel6 to add a 'dontbranch' file to cvs (at the time)
and then we mass branched all the rest of the packages into epel6. This
was good for adding in a lot of packages quickly, but resulted in some
packages that to this day never got a build (where maintainers decided
they didn't want to build/support, etc). 

So, I was thinking this time perhaps we could: 

* Setup a wiki page that contains all packages that are in rhel7beta.
(for reference)
* Setup another wiki page for epel7  
* As soon as there is a group of packages there, Branch them. 
* Keep the wiki page open until we are out of beta/rawhide mode and
  folks can mass add packages there for branching, process once a day
  or something. 
(this would avoid overloading scmadmins if someone wanted to branch a
bunch of packages). 

Thoughts or better ideas for branching? 

The rest of the process would include: 

* Setup git scripts to allow epel7 branches. 
(Default would be branch from f19)
(need to decide if the git branch name is el7 or epel7).
* Create gpg keys and add to signing server/verify pages. 
* Branch epel-release and add keys, etc. 
* Add koji tags and build targets, etc. 
* Add bugzilla version for bugs. 
* Probibly some wiki help to update things 
* Setup nightly cron job that composes epel7 in rawhide mode. 
* Don't depend on packages being signed until we exit rawhide mode. 
* Move from rawhide -> normal mode some time after rhel7 final is out
  (with 6 it was a few months after). 

Can anyone think of other things we need to do?

Any other general questions or comments ?

kevin