EPEL epel7 planning and processes

[T.C. Hollingsworth]

On Thu, Dec 12, 2013 at 5:07 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> 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).

Yeah, opt-in sounds like a much better idea.  :-)

> 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?

Any chance an automatic build could be tacked on the end of that?
Seems like it would be pretty easy to add to your wiki script and
would save packagers a little manual effort.  Of course, then you have
to worry about build order and such so it might not be worth the
trouble... :-(

> The rest of the process would include:
>
> * Setup git scripts to allow epel7 branches.
> (Default would be branch from f19)

Excellent.  F19 is exactly what I'd want for all my packages. :-)

> (need to decide if the git branch name is el7 or epel7).

"el7" please like the existing two?  Is there any particular reason
for it to be different?

> * Create gpg keys and add to signing server/verify pages.
> * Branch epel-release and add keys, etc.
> * Add koji tags and build targets, etc.

Will the koji tags for EPEL7 be dropping the "dist-" prefix like
Fedora did some time ago?

> * 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 ?

Thanks for getting the ball rolling on this quickly.  :-)

-T.C.