Scheduling issue for the 13.4 release
Product Priorities
-
PostgreSQL 12
Between now and 14.0 we continue to be on a faster paced PostgreSQL updating schedule to reach our longer term goal of catching up to the PostgreSQL release schedule and supporting two recent versions of PostgreSQL. The plan is to have PG 12 as the minimum required version and PG 13 as an opt-in version for %14.0. After this we will settle in to a pattern of one addition and one removal in every major release of GitLab. For %13.4 the focus will be testing PG12 with the Helm chart, and finishing upgrade documentation and any remaining items required to fully support PG12 as an opt-in version. See the PG 12 epic for more details.
-
OpenShift
We are continuing to work with RedHat on an operator that will support deploying and managing GitLab on OpenShift. The RedHat team has been leading the development effort to support backups and upgrades of GitLab. We will factor in time to review MRs and provide support, while also pushing forward with work to support using the Helm V3 SDK with the operator. The next steps from the Helm POC are evaluating the impact of replacing the standard pattern of hard coded objects with these dynamic ones, and the impact of that change throughout the codebase. Operating on the assumption that the impact will be low, but the value high, this should lead to a fast turn around and accelerated feature parity.
-
Cloud native maturity
There are two issues scheduled for 13.4 that will move the Cloud Native Installation category closer to the 'Complete' maturity level. The first is support for smartcards, which is one of the few remaining known limitations of the Helm install. The second is to document values and usage of the mailroom chart, which is part of the streamlined chart documentation epic.
-
Password encryption
MR is in review. We need to determine next steps for 13.4.
-
Orchestrator
In 13.4, Orchestrator work will focus on efficiency improvements such as ensuring idempotency, as well as support for node types recommended in the 2K reference architecture.
-
Supporting the .com migration
As we continue to migrate gitlab.com to Kubernetes, we are identifying aspects of the Helm install that could be problematic at very large scale. We will continue to prioritize these issues throughout the migration. This helps mature the Helm install and prove it out for large-scale deployments.
Deliverable Board
Issues on this board have already been reviewed and scheduled for the upcoming release. Each column represents a priority level. The highest ranked issues for each priority level are at the top of each column.
Priority board
Priority board categorizes the importance of all open issues, regardless of milestone. It's useful when looking for issues to consider for scheduling. Board includes issues from Omnibus, Charts, Team tasks projects.
Scheduling board
For Scheduling board is a work board used specifically during the scheduling process to provide an overview of candidates and get an idea of the next release before assigning the milestone to issues. Board includes issues from Omnibus, Charts, Team tasks projects.
Status
-
Collect initial candidate issues -
Issues added to the Deliverable board via label -
Scheduling boards sorted/arranged by importance -
Scheduling boards contain candidates from both Engineering and Product -
Scheduling boards scoped to a reasonable amount of work for the release -
Managers schedule the agreed issues for the release