On Dec 01 09:52, Jeff Sheltren wrote:
On Mon, Dec 1, 2014 at 9:36 AM, Brian Stinson bstinson@ksu.edu wrote:
Hi All,
I would like to start a discussion on where/how to ship the package building toolchain. Most of these tools shipped in EPEL, but deploying them to one of our repos would allow us to maintain our own patches if necessary and would eliminate any dependencies on 3rd party repositories for our core tools.
I'd much rather not do this for a couple reasons:
- CentOS Extras shouldn't overlap with EPEL.
- If there are reasons to customize/patch some of these things for the
CentOS infrastructure, perhaps they belong in a new/separate repo -- especially considering centos-extras is enabled by default.
1.) Some of the tools (koji especially) will require config customization, what is the best way to handle that?
Isn't there some configuration management system in place? Or maybe I'm misunderstanding the question...?
I definitely should have elaborated here. When using the koji client, we will be using Koji Profiles to distinguish between separate build systems (Fedora, CentOS CBS, on-prem koji etc.) These configs can be deployed a number of different ways, we could:
1.) ship upstream /etc/koji.conf (which points to nothing), and add the CBS config as the default
2.) ship /etc/koji.conf from EPEL but patch it so the CBS config is default
3.) ship /etc/koji.conf from EPEL and add a parallel installed CBS config that gets used by naming our koji cli tool /usr/bin/cbs
Personally, I'm partial to option 3 since it would be a little easier on EPEL developers who are also CentOS SIG developers. Although I could be convinced that having our configs as default (options 1 or 2) is necessary here.
2.) What should the testing -> release process look like after a koji build is done?
Are you planning to have a testing/staging Koji instance running for people to QA?
Since we are mostly talking about the clients, I was thinking about preparing the toolchain in one of the testing repos in the CBS and pointing developers there before the first release. It wouldn't be a bad idea to have a -testing repo for future releases.
--Brian