1.20 Planning

ehelms · July 23, 2018, 5:07pm

The ecosystem not just Foreman core. I would suggest plugin authors add a section so it’s clear the issues are for their plugin in the pinned thread.

ekohl · July 23, 2018, 5:20pm

On the other hand, here we are talking about the planning of Foreman 1.20 features. Plugins have their own release cycles. Unless the branching happens at the same time I’m not sure if it should be included here.

tbrisker · July 25, 2018, 1:15pm

Since each plugin has its own release schedule and process, I think it makes sense to open separate threads for every plugin that wishes to share their schedule and plans.

ehelms · July 25, 2018, 1:24pm

Personally, I’d find that more difficult to figure out the ecosystem unless we had a release category in discourse to limit things down to. But I am also looking at this from the perspective of plugins that tend to release in cadence or roughly in cadence.

tbrisker · July 25, 2018, 1:43pm

That’s actually a good idea. I made a releases category so we can put all of these threads in there instead of in the generic development category

lzap · July 25, 2018, 2:29pm

I know that last two times when I suggested this I failed, but can’t help myself.

Do we want to bump the version to 2.0 for smaller numbers? Again, my suggestion is for nothing, because IMHO if we start discussion which features are good candidates for major version change we won’t agree on anything and status quo will continue.

Why so many open-source project hesitate to bump major versions? Well, except Firefox and Chrome. It’s encoded in us that major version change must be huge. Vast majority of our releases were evolution, not revolution. Maybe it’s good time to start versioning scheme discussion, I would actually like calendar-based scheme since our cadence is fast and predictable for several years now.

http://calver.org/

Marek_Hulan · July 26, 2018, 6:48am

I think it might be good idea to list plugins and their target version here too. At least those whose maintainers want to have version branches compatible with given Foreman branch. E.g. I know that foreman_ansible for 1.20 will most likely be 3.0 and will contain ansible variables feature. I know we can always find out the list of compatible version ex-post through what we have in repos, but I think it wouldn’t be too much data and it might be good to have a list of plugin version generally compatible with the upcoming release.

bbuckingham · July 26, 2018, 3:13pm

Would it make sense to have the 1.20 Stabilization align to the end of a sprint? Many of the dev teams are currently working towards the same sprint schedule.

Below are the 2 sprints that are around the current Stabilization date:

sprint 39 : 2018-10-02
sprint 40 : 2018-10-22

tbrisker · July 26, 2018, 3:52pm

It could be a good idea to dedicate sprint 40 (assuming that’s the end date) to stabilization and testing of 1.20, if the various development teams agree to do that.

dLobatog · July 26, 2018, 5:25pm

It’s not encoded in us, but rather in semantic versioning (https://semver.org/). I don’t see anything inherently wrong with having 1.57079 if needed. We follow it nicely so that once plugins have breaking changes (incompatibility with Foreman old versions for example), they bump their major version.

I would advocate for bumping the major version once API v2 can be retired, for example, or upgrades break the workflow/automation scripts a lot.

thomasmckay · July 31, 2018, 6:53pm

Based on the replies above, I’d like to suggest that the pinned post be allowed to be edited for plugins that branch in sync with foreman. Specifically katello, but also any of the other foundational plugins that also follow that cadence.

Feature leads would be responsible for updating their section of any plugin with relevant PRs (or redmine issues?) for highlighting the work.

I personally really like this all-in-one-place post that may be easily referenced. Thanks for putting it together @tbrisker

bbuckingham · July 31, 2018, 7:47pm

I tend to agree with Tom. It was also suggested by Eric and Marek.

While it isn’t true for all plugins, there are a set of core plugins that follow closely and align with the foreman core release. In order to ensure that all are working together closely and towards the same goal, it seems reasonable that we’d have a single place to define the overall milestones and high-level plans.

I think this thread is an enormous step forward. Thanks for initiating it @tbrisker.

Is it permitted for plugin owners and feature leads to add sections to the above wiki?

tbrisker · August 1, 2018, 7:25am

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

bbuckingham · August 6, 2018, 12:24pm

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.

tbrisker · August 15, 2018, 12:31pm

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

tbrisker · October 11, 2018, 8:39am

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.

iNecas · October 12, 2018, 3:05pm

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

tbrisker · October 16, 2018, 7:15pm

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

ehelms · October 16, 2018, 7:58pm

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

tbrisker · October 18, 2018, 12:44pm

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:

Bug fixes only. New features will have to wait 3 months for the next release, even if they are small and low risk.
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.
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.
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.