[foreman-dev] Moving katello-packaging to foreman-packaging
Per the previous plan proposal, for which no objections were raised, I have started this migration process. There are a number of grouped PRs open to foreman-packaging [1] to move the various packages into a `katello/` sub-directory for now. There is a large PR open to katello-packaging to inevitably remove and deprecate the repository (except for Katello 3.5 and below) [2]. [1] https://github.com/theforeman/foreman-packaging/pulls [2] https://github.com/Katello/katello-packaging/pull/575 -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Moving Katello packaging to Foreman packaging
On Wed, Feb 22, 2017 at 03:01:54PM -0500, Eric D Helms wrote: > I have opened a PR to foreman-packaging with the intent of centralizing a > large chunk of community plugin packaging to foreman-packaging so that we > are all working from the same repository. Further, the intent of this would > be to centralize published repositories as well which would allow better > metrics gathering and single place for users to go. > > I've laid out what the PR does and the benefits on the PR itself. So any > discussion of what it provides or how we are pulling it in should be > relegated to the PR. However, I wanted to bring some awareness to this > (since we wish to do this for Katello 3.4 release) and to look ahead. > > The current PR moves all katello-packaging to foreman-packaging but > maintains the repository structure. That is, Katello would still have its > own repository with a Pulp, Candlepin and Client repository. This will > allow for a separation and non-interference with current Foreman and > Plugins. Further, this allows Katello's testing pipeline to continue > working and being gated by testing. > > Looking ahead beyond the 3.4 release, we could start to then look at: > > * single Foreman Client repository which would include all client tools > (e.g. the openscap client tool, katello-agent) > * smarter plugin releasing with gating defined by a plugin > > I would appreciate any feedback, agreement to or input towards this idea, > and the initial implementation so we can adjust and test nightlies prior to > the 3.4 branch date (~3 weeks away). Without looking at all the details I do support the effort. Having a single repository which includes both Foreman and Katello would simplify life for users, in our installer and CI pipeline. Note that single could also mean the plugins repository. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] Moving Katello packaging to Foreman packaging
All, I have opened a PR to foreman-packaging with the intent of centralizing a large chunk of community plugin packaging to foreman-packaging so that we are all working from the same repository. Further, the intent of this would be to centralize published repositories as well which would allow better metrics gathering and single place for users to go. I've laid out what the PR does and the benefits on the PR itself. So any discussion of what it provides or how we are pulling it in should be relegated to the PR. However, I wanted to bring some awareness to this (since we wish to do this for Katello 3.4 release) and to look ahead. The current PR moves all katello-packaging to foreman-packaging but maintains the repository structure. That is, Katello would still have its own repository with a Pulp, Candlepin and Client repository. This will allow for a separation and non-interference with current Foreman and Plugins. Further, this allows Katello's testing pipeline to continue working and being gated by testing. Looking ahead beyond the 3.4 release, we could start to then look at: * single Foreman Client repository which would include all client tools (e.g. the openscap client tool, katello-agent) * smarter plugin releasing with gating defined by a plugin I would appreciate any feedback, agreement to or input towards this idea, and the initial implementation so we can adjust and test nightlies prior to the 3.4 branch date (~3 weeks away). Thanks, Eric [1] https://github.com/theforeman/foreman-packaging/pull/1541 -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.