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
branch from EPEL6?
How to deal with systemd related things?
Is it possible to branch from branches determined by packagers?
On Thu, Dec 12, 2013 at 6:01 PM, Christopher Meng cickumqt@gmail.com wrote:
branch from EPEL6?
He said F19. :-) That makes a lot more sense IMHO.
How to deal with systemd related things?
Generally, EPEL follows the Fedora Packaging Guidelines, so systemd units would be required for all new packages starting with EPEL7. Though I guess existing packages would be grandfathered in like they were with Fedora...
If we're branching from F19, hopefully packagers have got the systemd stuff figured out already. They've had three years to prepare...
Now that you mention it though, I wonder if we should bother with the systemd-sysv-convert stuff [1] for EPEL7? It got dropped from the Fedora guidelines (again, because it's been three years...) and Lennart seemed to think it was a bad idea in general, but the utility is indeed shipped in the RHEL 7 beta.
In the past, this would have been handwaved away by saying RHEL doesn't support upgrades, but rumor has it that this won't be the case this time around. ;-)
Anyone have any idea whether RH used the systemd-sysv-convert scriptlets for their packages? I guess we should just follow them here...
-T.C.
[1] https://fedoraproject.org/w/index.php?title=Packaging:ScriptletSnippets&...
On Thu, Dec 12, 2013 at 6:52 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
Anyone have any idea whether RH used the systemd-sysv-convert scriptlets for their packages? I guess we should just follow them here...
Right after I sent this I remembered that `rpm -q --triggers` is a thing that exists, and the answer seems to be "yes". Though that might not necessarily be on purpose...
So we might need an EPEL7-specific guideline for this, then. :-/
-T.C.
On Thu, 12 Dec 2013 18:52:38 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
On Thu, Dec 12, 2013 at 6:01 PM, Christopher Meng cickumqt@gmail.com wrote:
branch from EPEL6?
He said F19. :-) That makes a lot more sense IMHO.
Right. New epel7 branches would get the content from the f19 branch to start with. You can of course then commit whatever you like over that. If folks really don't like that, we could also just make them completely clean and ask people to re-import, but that seems like a hassle to me.
How to deal with systemd related things?
Generally, EPEL follows the Fedora Packaging Guidelines, so systemd units would be required for all new packages starting with EPEL7. Though I guess existing packages would be grandfathered in like they were with Fedora...
I wouldn't think so no. I would say all epel7 packages MUST use systemd units. I don't know the state of the systemd rpm macros in rhel7, we would need to figure that out. Hopefully they are all there.
If we're branching from F19, hopefully packagers have got the systemd stuff figured out already. They've had three years to prepare...
Yep.
Now that you mention it though, I wonder if we should bother with the systemd-sysv-convert stuff [1] for EPEL7? It got dropped from the Fedora guidelines (again, because it's been three years...) and Lennart seemed to think it was a bad idea in general, but the utility is indeed shipped in the RHEL 7 beta.
IMHO, we should not allow sysvinit stuff at all. It's just a hassle and everyone should have already migrated anyhow.
In the past, this would have been handwaved away by saying RHEL doesn't support upgrades, but rumor has it that this won't be the case this time around. ;-)
Yeah, I worry about that. We may want to say that EPEL doesn't support them. I mean, upgrade path from epel6 is something we could easily check and ask people to keep working, but there's lots of packages I suspect where upgrades are a lot more complex... Perhaps we should say "it might work, but if not, sorry"
Anyone have any idea whether RH used the systemd-sysv-convert scriptlets for their packages? I guess we should just follow them here...
No idea, but Fedora 19 packages should already be using systemd units and I don't think we should allow packages that don't into epel7.
kevin
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi kevin@scrye.com wrote:
I wouldn't think so no. I would say all epel7 packages MUST use systemd units. I don't know the state of the systemd rpm macros in rhel7, we would need to figure that out. Hopefully they are all there.
+1000 from me. Won't be sad to see the death of those things. ;-)
Now that you mention it though, I wonder if we should bother with the systemd-sysv-convert stuff [1] for EPEL7? It got dropped from the Fedora guidelines (again, because it's been three years...) and Lennart seemed to think it was a bad idea in general, but the utility is indeed shipped in the RHEL 7 beta.
IMHO, we should not allow sysvinit stuff at all. It's just a hassle and everyone should have already migrated anyhow.
Well, systemd-sysv-convert is an upgrade thing that lets you transfer enabled/disabled status from your old initscripts to your shiny new systemd units. It's useful even in a mystical initscript-free future.
That being said, if you're the type of person who runs RHEL, you're probably a.) paranoid about automatic _anything_ b.) using ansible/puppet/whatever to manage that kind of thing anyway and/or c.) going to want to go over your enabled services with a fine-toothed comb post-upgrade regardless.
So it's probably not worth bothering about.
In the past, this would have been handwaved away by saying RHEL doesn't support upgrades, but rumor has it that this won't be the case this time around. ;-)
Yeah, I worry about that. We may want to say that EPEL doesn't support them. I mean, upgrade path from epel6 is something we could easily check and ask people to keep working, but there's lots of packages I suspect where upgrades are a lot more complex... Perhaps we should say "it might work, but if not, sorry"
"If it breaks you get to keep both pieces" ought to be Fedora's fifth foundation. :-P
I think that EVR upgrade path issues should be fixed, because seriously how hard is it to fix that?
We really don't provide any sort of assurance on upgrades beyond that even in Fedora. If something changes config file format or whatever, you're generally expected to deal with it yourself. I don't see how EPEL would be any different.
-T.C.
On Thu, Dec 12, 2013 at 5:07 PM, Kevin Fenzi kevin@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.
On Thu, 12 Dec 2013 18:36:48 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
...snip...
Yeah, opt-in sounds like a much better idea. :-)
Yeah, it does mean slower, but I think it's good to only have those things in that are for sure maintained.
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... :-(
Yeah, build order, if they want to adjust the packaging before building, if they are ready to build then, etc, etc. So, IMHO, a auto build is not a good idea.
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?
We might go with epel7. The reason is that some people seem to have confusion about the branches being 'elN'. "Oh, this is rhel6" No, it's epel6, not rhel.
Overall pretty minor either way.
- 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?
Yeah, I talked with Dennis and yes, he wants to make them not use dist. :)
- 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).
One more thing to add: * add epel7 comps file to git comps. (Dennis already did this).
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. :-)
No problem. Probibly would be moving even faster, except we have a Fedora 20 to get released. ;)
kevin
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 12 Dec 2013 18:36:48 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
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... :-(
Yeah, build order, if they want to adjust the packaging before building, if they are ready to build then, etc, etc. So, IMHO, a auto build is not a good idea.
Ack.
(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?
We might go with epel7. The reason is that some people seem to have confusion about the branches being 'elN'. "Oh, this is rhel6" No, it's epel6, not rhel.
Overall pretty minor either way.
Yeah, I have some shell functions and little scripts that would have to be adjusted, but they'd need to be adjusted to {6,7} anyway, so whatever.
-T.C.
On Fri, Dec 13, 2013 at 7:23 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 12 Dec 2013 18:36:48 -0700 We might go with epel7. The reason is that some people seem to have confusion about the branches being 'elN'. "Oh, this is rhel6" No, it's epel6, not rhel.
Overall pretty minor either way.
Yeah, I have some shell functions and little scripts that would have to be adjusted, but they'd need to be adjusted to {6,7} anyway, so whatever.
My preference is for "el7", since it's shorter to type :)
- Ken
On 14.12.2013 03:56, Ken Dreyer wrote:
On Fri, Dec 13, 2013 at 7:23 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 12 Dec 2013 18:36:48 -0700 We might go with epel7. The reason is that some people seem to have confusion about the branches being 'elN'. "Oh, this is rhel6" No, it's epel6, not rhel.
Overall pretty minor either way.
Yeah, I have some shell functions and little scripts that would have to be adjusted, but they'd need to be adjusted to {6,7} anyway, so whatever.
My preference is for "el7", since it's shorter to type :)
My preference is also "el7", because we have also a "Packager" and "Vendor" tag to declare these packages as Fedora EPEL (and not rhel) packages.
That's also an interesting thing when rebuilding CentOS packages to match the upstream dist tag.
Best regards,
Morten
On Wed, Dec 18, 2013 at 6:58 AM, Morten Stevens mstevens@fedoraproject.org wrote:
My preference is also "el7", because we have also a "Packager" and "Vendor" tag to declare these packages as Fedora EPEL (and not rhel) packages.
Why should these 2 tags be used still?
On 12/19/2013 12:57 PM, Christopher Meng wrote:
On Wed, Dec 18, 2013 at 6:58 AM, Morten Stevens mstevens@fedoraproject.org wrote:
My preference is also "el7", because we have also a "Packager" and "Vendor" tag to declare these packages as Fedora EPEL (and not rhel) packages.
Why should these 2 tags be used still?
because there are a zillion 3rd party repos and those tags are used to differentiate them
Hi,
Dne pátek, 13. prosince 2013 17:42:24 CEST, Kevin Fenzi napsal(a):
On Thu, 12 Dec 2013 18:36:48 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
...
Yeah, opt-in sounds like a much better idea. :-)
Yeah, it does mean slower, but I think it's good to only have those things in that are for sure maintained.
-1 from me, if I get you right that everyone should ack the packages to be branched
I often don't find enough time for the things I'm not paid for, so I see a potential to miss some "please add your package if you want to have it in EPEL7" plea
but that doesn't mean I'd call these things "unmaintained", just the response times are a bit longer ...
K.
What's the process opt-in at this point? I'm a bit unclear. I see that epel-release was built for EPEL7 (and that the git branch is epel7 instead of el7).
On Wed, Dec 25, 2013 at 3:03 AM, Karel Volný kvolny@redhat.com wrote:
Hi,
Dne pátek, 13. prosince 2013 17:42:24 CEST, Kevin Fenzi napsal(a):
On Thu, 12 Dec 2013 18:36:48 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
...
Yeah, opt-in sounds like a much better idea. :-)
Yeah, it does mean slower, but I think it's good to only have those things in that are for sure maintained.
-1 from me, if I get you right that everyone should ack the packages to be branched
I often don't find enough time for the things I'm not paid for, so I see a potential to miss some "please add your package if you want to have it in EPEL7" plea
but that doesn't mean I'd call these things "unmaintained", just the response times are a bit longer ...
K.
-- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Thu, 26 Dec 2013 16:53:19 -0800 Michael Stahnke stahnma@puppetlabs.com wrote:
What's the process opt-in at this point? I'm a bit unclear. I see that epel-release was built for EPEL7 (and that the git branch is epel7 instead of el7).
There's no process yet because we don't have some things we still need done yet. ;)
Dennis is working on getting fedup and mock and such in place. Once those are working we should be able to get a good compose (it's currently enabled, but just failing every night due to missing items).
I expect things will start moving along after the holidays and as soon as things are ready for more packages we will announce. ;)
kevin
On Thu, Dec 26, 2013 at 6:12 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 26 Dec 2013 16:53:19 -0800 Michael Stahnke stahnma@puppetlabs.com wrote:
What's the process opt-in at this point? I'm a bit unclear. I see that epel-release was built for EPEL7 (and that the git branch is epel7 instead of el7).
There's no process yet because we don't have some things we still need done yet. ;)
Dennis is working on getting fedup and mock and such in place. Once those are working we should be able to get a good compose (it's currently enabled, but just failing every night due to missing items).
I expect things will start moving along after the holidays and as soon as things are ready for more packages we will announce. ;)
http://www.karan.org/blog/2014/01/02/an-epel-build-in-rhel7b1/ That isn't anything official, but it let me see that my EPEL packages built just fine on EL7 beta and is probably a decent indicator of potential problems in a general sense.
On Wed, 25 Dec 2013 12:03:47 +0100 Karel Volný kvolny@redhat.com wrote:
Hi,
Dne pátek, 13. prosince 2013 17:42:24 CEST, Kevin Fenzi napsal(a):
On Thu, 12 Dec 2013 18:36:48 -0700 "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
...
Yeah, opt-in sounds like a much better idea. :-)
Yeah, it does mean slower, but I think it's good to only have those things in that are for sure maintained.
-1 from me, if I get you right that everyone should ack the packages to be branched
I often don't find enough time for the things I'm not paid for, so I see a potential to miss some "please add your package if you want to have it in EPEL7" plea
But by our own policies someone who submits such a plea only has to wait a week and if you don't answer, they can branch and maintain. A active involved maintainer seems like a win there over "oh, I'll fire off a build and hope it works and won't have time to look at any bugs"
but that doesn't mean I'd call these things "unmaintained", just the response times are a bit longer ...
Sure, we are all busy. ;)
Thats just a good chance to bring in a co-maintainer that does have more time, etc.
kevin
Hi,
...
But by our own policies someone who submits such a plea only has to wait a week and if you don't answer, they can branch and maintain. A active involved maintainer seems like a win there over "oh, I'll fire off a build and hope it works and won't have time to look at any bugs"
...
Thats just a good chance to bring in a co-maintainer that does have more time, etc.
if you have any spare "active involved maintainers" or "co-maintainers that do have more time", that's great and I'd be glad to leave the care about the packages to someone more responsible
but if you don't have them .. then "fire off a build and hope it works" seems to me still a better option than not having the software packaged at all :-/
K.
On 12/12/2013 05:07 PM, Kevin Fenzi wrote:
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).
Opt in is good. Any process for easy mass branching that works for the admins works for me.
The rest of the process would include:
- Setup git scripts to allow epel7 branches.
(Default would be branch from f19)
Works for me.
(need to decide if the git branch name is el7 or epel7).
el7
- Create gpg keys and add to signing server/verify pages.
- Branch epel-release and add keys, etc.
- Add koji tags and build targets, etc.
simplified names here too.
- 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. Looking forward to EL7.
El Thu, 12 Dec 2013 17:07:34 -0700 Kevin Fenzi kevin@scrye.com escribió:
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)
Done
(need to decide if the git branch name is el7 or epel7).
I went with epel7 it matches pkgdb and koji, to me it is much cleaner and clearer. (note you will need the fedpkg update that I built today to build.
- Create gpg keys and add to signing server/verify pages.
gpg keys created, need to finish the steps
- Branch epel-release and add keys, etc.
Done
- Add koji tags and build targets, etc.
Done
- Add bugzilla version for bugs.
Added, i also disabled epel4
- Probibly some wiki help to update things
- Setup nightly cron job that composes epel7 in rawhide mode.
Just needs some tweaking and enabling should be done soon.
- Don't depend on packages being signed until we exit rawhide mode.
epel.repo has gpgcheck=0 currently. Im open to changing it. but we can't guarantee that all packages are always signed.
- Move from rawhide -> normal mode some time after rhel7 final is out (with 6 it was a few months after).
I think we waited for CentOS 6 to come out
Can anyone think of other things we need to do?
Any other general questions or comments ?
kevin
El Sun, 15 Dec 2013 23:01:15 -0600 Dennis Gilmore dennis@ausil.us escribió:
El Thu, 12 Dec 2013 17:07:34 -0700 Kevin Fenzi kevin@scrye.com escribió:
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)
done https://fedoraproject.org/wiki/EPEL/epel7
- 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)
Done
(need to decide if the git branch name is el7 or epel7).
I went with epel7 it matches pkgdb and koji, to me it is much cleaner and clearer. (note you will need the fedpkg update that I built today to build.
- Create gpg keys and add to signing server/verify pages.
gpg keys created, need to finish the steps
- Branch epel-release and add keys, etc.
Done
- Add koji tags and build targets, etc.
Done
- Add bugzilla version for bugs.
Added, i also disabled epel4
- Probibly some wiki help to update things
- Setup nightly cron job that composes epel7 in rawhide mode.
Just needs some tweaking and enabling should be done soon.
- Don't depend on packages being signed until we exit rawhide mode.
epel.repo has gpgcheck=0 currently. Im open to changing it. but we can't guarantee that all packages are always signed.
- Move from rawhide -> normal mode some time after rhel7 final is
out (with 6 it was a few months after).
I think we waited for CentOS 6 to come out
Can anyone think of other things we need to do?
Any other general questions or comments ?
kevin
On Sun, Dec 15, 2013 at 9:48 PM, Dennis Gilmore dennis@ausil.us wrote:
Thanks Dennis, for setting all this up! Where does this leave us now? Can people start submitting builds already, or are we still missing some infrastructure pieces?
-Jeff
On Mon, 16 Dec 2013 09:06:06 -0800 Jeff Sheltren jeff@tag1consulting.com wrote:
On Sun, Dec 15, 2013 at 9:48 PM, Dennis Gilmore dennis@ausil.us wrote:
Thanks Dennis, for setting all this up! Where does this leave us now? Can people start submitting builds already, or are we still missing some infrastructure pieces?
There's still a bit more to do before we can open things up.
epel-release needs a bit of work and we need to get this added to mirrormanager.
Hopefully in the next few days it will be ready to start branching/building things. :)
kevin
On Mon, Dec 16, 2013 at 10:10:56AM -0700, Kevin Fenzi wrote:
On Mon, 16 Dec 2013 09:06:06 -0800 Jeff Sheltren <jeff at tag1consulting.com> wrote:
On Sun, Dec 15, 2013 at 9:48 PM, Dennis Gilmore <dennis at ausil.us> wrote:
Thanks Dennis, for setting all this up! Where does this leave us now? Can people start submitting builds already, or are we still missing some infrastructure pieces?
There's still a bit more to do before we can open things up.
epel-release needs a bit of work and we need to get this added to mirrormanager.
Mirrormanager is done as of late last night.
Thanks, Matt
epel-devel@lists.fedoraproject.org
-
Christopher Meng -
Dave Johansen -
Dennis Gilmore -
Jeff Sheltren -
Karel Volný -
Ken Dreyer -
Kevin Fenzi -
Manuel Wolfshant -
Matt Domsch -
Michael Stahnke -
Morten Stevens -
Orion Poplawski -
T.C. Hollingsworth