On Dec 01 09:52, Jeff Sheltren wrote: > On Mon, Dec 1, 2014 at 9:36 AM, Brian Stinson <bstinson at 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: > 1. CentOS Extras shouldn't overlap with EPEL. > 2. 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