The agenda for today’s meeting.
Schedule | 3.9.0 TODO | CI overview
- We’re nearing the end of the development cycle, which means it’s almost time to post the branching procedure (see branching).
Schedule | 3.8.0 TODO | CI overview
3.7.1 TODO | 3.7.1 DONE | CI overview
Present: @pcreech (chair), @ekohl (notes), @Griffin-Sullivan, @iballou, @Odilhao
- Need to do some Redmine bookkeeping
- 3.7.1 release process posted: Foreman 3.7.1 release process
- Either released today or early next week due to people having time off on Thursday and releasing on Friday is a bad practice.
- Release owner: @iballou
- Release engineer: @Odilhao
- Work under way to update Pulp from 3.28 to 3.40. Given how close branching is, this may be tight.
- @Odilhao is working on the packaging side of it.
- Verification used to happen with pulp-installer, but that’s discontinued so @Odilhao and @ekohl will discuss using the foreman-installer parts to verify Pulp as part of the release pipeline
- We used to increase release team meeting to twice a week around branching, but didn’t do so in the past few releases. Starting stabilization week we’ll also meet on Mondays.
If you have a source repo that performs this foreman-installer based verification, that you can point me at (or even a line of code) I would be interested.
I guess what I am still interested in would be the line in pulpcore-packaging (or whatever CI pipeline uses pulpcore-packaging to build a new package) that then runs
puppet-pulpcore after building a new pulp package. I am guessing that line may not yet exist yet, because @Odilhao and @ekohl have yet to build it?
Yeah, that line doesn’t exist yet.
Correct, the discussion is about how to move forward with it. I made a proof of concept almost a year ago: Restructure installation and add a pulp scenario by ekohl · Pull Request #822 · theforeman/foreman-installer · GitHub.
But @ehelms is also looking at building a separate repository for Candlepin (Add Candlepin pipeline by ehelms · Pull Request #361 · theforeman/jenkins-jobs · GitHub) which would then need similar testing.
Restructure installation to avoid duplicate files by ekohl · Pull Request #870 · theforeman/foreman-installer · GitHub would be the first step. Together with a packaging change the aim is to make it easier to ship multiple installer scenarios.