On Mon, Oct 23, 2017 at 5:57 AM, Daniel Lobato Garcia <[email protected]> wrote:
> On 10/20, Eric D Helms wrote: > > All, > > > > One of the items on the Roadmap I've sent out is centralizing packaging > > into a single repository. The last time I tried this I attempted to go > > whole hog migrating all things all at once. In order to make this more > > approachable, and to encourage reviews, I would like to follow the > > following plan in this rough order for nightlies only: > > > > 1) Move comps to foreman-packaging and update mash scripts > > 2) copy releasers and tito.props to foreman-packaging for katello > > repositories > > 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly > RPMs > > (rubygem-katello, hammer_cli_katello, and katello-installer) for last. > This > > will involve a PR to foreman-packaging and PR to katello-packaging adding > > to the former and removing from the latter. > > 4) Update katello-packaging README to indicate deperecation > > > > I am sending this plan along to gather feedback, find holes in the plan > and > > to get approval/disapproval from the community in taking this step. > > > > My plan would be to begin this migration towards the end of next week. > > I think it sounds great, ping me when you submit these PRs if you want > someone > to take a look. > > Would koji be affected by this? For example, new katello packages in the > foreman-packaging repository would need to be in foreman tags or still the > katello tags? If the latter, any reason why it would not make sense to > change that > to treat it like any other plugin? > Koji has no binding to the git repository, as long as the releasers tag target Katello's (for the releasers I plan to bring over) then it will release the package to the standard Katello tags. There are a few forces at play in order to get Katello to be treated like other plugins: 1) Move the git packaging to the same repository 2) Devise a plan that allows any plugin to be individually tested and committed to Koji or pushed to the repositories. 3) Revise Foreman yum repository structure to handle Pulp, Candlepin and Client repositories (per https://groups.google.com/forum/#!searchin/foreman-dev/repos%7Csort:date/foreman-dev/6j0itrYnuJo/poJPo2FFAQAJ ) 4) Solve the bandwidth issue (Greg mentioned they are working on this) There are rough plans in place for everything but #2. And given that today, Katello runs a system level test before pushing this one is imperative for assuring the same level of assurance in the code. > > > > > -- > > 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
