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 propose that the following packages be released into CentOS-Extras when they are ready:
Package Primary Contact/Maintainer ======= ========================== centpkg bstinson GitPython bstinson koji alphacc python-async bstinson python-gitdb bstinson python-smmap bstinson rpkg bstinson
To support this, I also propose that the appropriate 'extras' build targets be created (or that we designate existing tags) in the CBS.
Things we should discuss:
1.) Some of the tools (koji especially) will require config customization, what is the best way to handle that?
2.) What should the testing -> release process look like after a koji build is done?
Cheers! Brian
-- Brian Stinson bstinson@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
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: 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...?
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?
-Jeff
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
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.
Good points. Would a separate cbs-tools repo, with a cbs-tools-release package in CentOS-Extras be acceptable?
--Brian
On Thu, Dec 4, 2014 at 8:20 AM, Brian Stinson bstinson@ksu.edu wrote:
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.
Good points. Would a separate cbs-tools repo, with a cbs-tools-release package in CentOS-Extras be acceptable?
Sounds like a good approach to me.
-Jeff
On 04/12/14 16:20, Brian Stinson wrote:
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.
Good points. Would a separate cbs-tools repo, with a cbs-tools-release package in CentOS-Extras be acceptable?
that might work, but why do we not want centos-extras to overlap EPEL ? Iirc, it already does this.
- KB
On Mon, Dec 15, 2014 at 8:06 AM, Karanbir Singh mail-lists@karan.org wrote:
Good points. Would a separate cbs-tools repo, with a cbs-tools-release package in CentOS-Extras be acceptable?
that might work, but why do we not want centos-extras to overlap EPEL ? Iirc, it already does this.
- KB
Ahh, I forgot we did this. I do see some overlapping packages, but I'm not sure why we do so. It'd be great to keep the overlap minimal IMO.
That said, it seems that people installing these packages are a *very* small percentage of CentOS users. Is there a good reason to put these packages in a default-enabled repo (extras) for all CentOS installs? I'd think a separate "CBS" repo would allow for a bit more flexibility going forward -- especially if it turns out we have more conflicting packages (with EPEL or whatever other repos).
-Jeff
On 15/12/14 16:24, Jeff Sheltren wrote:
On Mon, Dec 15, 2014 at 8:06 AM, Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org> wrote:
> Good points. Would a separate cbs-tools repo, with a cbs-tools-release > package in CentOS-Extras be acceptable? that might work, but why do we not want centos-extras to overlap EPEL ? Iirc, it already does this. - KB <http://lists.centos.org/mailman/listinfo/centos-devel>Ahh, I forgot we did this. I do see some overlapping packages, but I'm not sure why we do so. It'd be great to keep the overlap minimal IMO.
That said, it seems that people installing these packages are a *very* small percentage of CentOS users. Is there a good reason to put these packages in a default-enabled repo (extras) for all CentOS installs? I'd think a separate "CBS" repo would allow for a bit more flexibility going forward -- especially if it turns out we have more conflicting packages (with EPEL or whatever other repos).
the biggest issue is that we have no way to feedback into EPEL, till we can resolve that part of the equation its just a downstream from CentOS - and setting a user experience in the platform remains on their plate.
Having said that, as long as we remain a higher EVR than the corrosponding EPEL package, or at the exact same EVR, there should be no repo flapping, and it should be a fairly consistent user experience.
w.r.t koji, it would be about the same thing. however, given the potential userbase is going to be even smaller, it can go into its own repo with a -release rpm in -Extras/
-
Brian Stinson -
Jeff Sheltren -
Karanbir Singh