1.20 Planning


#22

Sure, I’m fine with adding plugins as well as long as they plan to release with the same timeline, go ahead.


#23

Thanks @tbrisker! I have added a section for Katello and included in it a few of the things that I know the team is actively working on for inclusion in to the release.

If anyone would like to add items to the Katello 3.9 list or if you’d like to add another plugin that is following the same schedule, please do so.


#24

Considering about 1 month has passed and we have just 2 more until branching, would people be interested in having an open call next week to discuss the roadmap - go over the issues, see their status and what can be done to get them merged in time or if we prefer to push them out to the next release?

  • Yes
  • No

0 voters


#25

Oops, looks like I dropped the ball on the 1.20 planning meeting discussed above. considering the demand, I’ll try to schedule one for 1.21 perhaps a bit earlier in the cycle.

Regarding the 1.20 process:
We are going forward with branching next week, with RC1 planned within a few days after branching.
Some issues we were having with nightlies packaging have been fixed (thanks @ekohl!) and we are continuing to investigate others.
Last night RPM nightlies have been built successfully for both foreman and katello, so testing on them can continue in the hope of finding bugs even prior to RC1.
Debian nightlies are still having some issues passing tests and therefor are not being published, if anyone can take a look into it that would be appreciated.


#26

FYI I did installed foreman + katello + couple of plugins today in production (and FIPS enabled) and the installer went just fine (at the time of testing, I needed a scratch rpm with latest remote execution builds, but by the time I’m writing this, it has been already merged, and next nightlies should b ready

foreman-installer --scenario katello \
         --enable-foreman-plugin-ansible \
         --enable-foreman-plugin-discovery \
         --enable-foreman-plugin-bootdisk \
         --enable-foreman-plugin-hooks \
         --enable-foreman-plugin-openscap \
         --enable-foreman-plugin-templates \
         --enable-foreman-plugin-remote-execution \
         --enable-foreman-proxy-plugin-remote-execution-ssh \
         --enable-foreman-proxy-plugin-discovery \
         --enable-foreman-proxy-plugin-ansible \
         --enable-foreman-proxy-plugin-openscap \
         --enable-foreman-cli-discovery \
         --enable-foreman-cli-openscap \
         --enable-foreman-cli-remote-execution \
         --enable-foreman-cli-tasks \
         --enable-foreman-cli-templates

Looks like we’re in a good shape for branching next week: let’s not break anything :slight_smile:


#27

Quick update: due to some issues with nightlies that were found today, branching will be delayed. Hopefully all issues are now resolved and the branching process can continue tomorrow. If you want to closely follow the branching progress, please head over to Foreman 1.20 branching process


#28

Foreman core nightlies are green now. Katello nightlies are failing due to 3.7.1 package signing issues but that is being resolved.


#29

Foreman core projects have all been branched for 1.20 and RC1 process is underway. Feel free to resume normal operations when merging into development branches.

If you run into any PRs that you think should be pulled into 1.20 prior to the GA release please bring them to my attention.
To help you understand what qualifies for being pulled in, let me share the general criteria I use for consideration:

  1. Bug fixes only. New features will have to wait 3 months for the next release, even if they are small and low risk.
  2. Risk of something breaking unexpectedly as a result. The lower the risk, the better the chances. Examples of some things that raise the risk: DB migrations, packaging changes, large refactoring.
  3. Impact on users. Issues blocking many users’ workflows, such as provisioning breaking, will be pulled in faster than issues that can be easily worked around.
  4. Timelines. If the request comes too late to pull into an RC, or requires creating another RC to verify and puts the timeline for GA at risk, the impact will have to be proportionally significant to justify the delay.