Milestone 15.6 review and discussion
🚀
Milestone 15.6 Helpful links | Use this for |
---|---|
Functional breakdown | Viewing issues scheduled for the current and next several milestones. |
Milestone board | See how the planned issues are broken down by function. |
Workflow board | See how the milestone issues are broken down by their current status (workflow). |
List of P1 unweighted issues | A list of issues that are not yet weighted, which is a requirement for P1 issues. |
Issues that need refining | A list of issues that refinement |
Issue types by milestone | See the ratio of features, maintenance, and bugs |
🌴
Holidays
Please order by From date
Person | From | To |
---|---|---|
Tim | Oct. 17 | Oct. 17 |
Jaime | Oct. 19 | Oct. 19 |
Jaime | Oct. 21 | Oct. 21 |
Rahul | Oct. 21 | Oct. 21 |
Dima | Oct. 24 | Oct. 24 |
Hayley | Oct. 24 | Oct. 24 |
Jaime | Oct. 31 | Nov. 2 |
Rahul | Oct. 31 | Oct. 31 |
Sofia | Oct. 31 | Oct. 31 |
João | Nov. 1 | Nov. 1 |
Adie | Nov. 10 | Nov 11 |
Hayley | Nov. 11 | Nov. 25 |
Michelle | Nov. 15 | Nov. 17 |
📦
Capacity - In %15.6, Steve will transition to the Delivery team. We will be at reduced capacity on the Package Registry side for a while. As such, we will plan a minimal amount of rails issues.
- Katie is transferring to the Data Science team. Katie will dedicate 50% of her time to Package until we hire a new UX designer.
- We've had several new team members join, and we will be helping them to onboard in %15.6.
- Say/Do dashboard
🕰
Past 3 milestone commitments Milestone | Deliverable issues planned | Deliverable issues delivered | Deliverable issues rescheduled | Average weight | Total weight |
---|---|---|---|---|---|
15.6 | 11 | 2.00 | 22 | ||
15.5 | 21 | 1.80 | 38 | ||
15.4 | 24 | 1.79 | 43 | ||
15.3 | 17 | 1.41 | 24 |
🎯
Goals What are we doing, and why is it important?
- The primary goal of %15.6 is to improve storage management and storage calculations for the Package and Container Registries. Why? Because GitLab announced new storage limits and will enforce those limits in Q4. We need to ensure we are accurately reporting costs to customers.
- Improve the stability and performance of the Container Registry. Why? Now that we have the new registry on GitLab.com, we can begin to make some long-overdue, much-needed improvements. The goal is to stabilize the registry in preparation for new feature development and the self-managed rollout.
- Finish the Maven request forwarding rollout. Why? Because this new feature and the related settings will help many Package Registry users to be more efficient and secure.
P1 (Deliverable) Issues 🦊
Please remember to make time in each milestone for learning and personal projects in addition to the below list.
Security Issues
By prioritizing security-related issues, we can help reduce GitLab's threat landscape by reducing the likelihood of breach, the exposure and severity of vulnerabilities, the cost associated with service vulnerabilities.
Container Registry
%15.6 has a heavy focus on the Container Registry. First, we need to improve the storage consumption calculation and reliability. Second, we need to support the Redis rollout and build an implementation plan for active database load balancing. We also need to improve the notifications system so that we can unblock user-level data, webhooks for registry updates, and other features. Finally, there will also be work required to either archive or delete data duplicated during the migration.
-
Scaling limitations on top-level namespace usage calculation customer -
Images are not being properly deleted from the Container Registry UI Support Priority -
Build an implementation plan for Container Registry active database load balancing performance-refinement -
Support rollout of Redis to cache database repository objects in gprd
performance-refinement -
refactor(handlers): send notification events explicitly in the handlers -
Remove tmp_idx_container_repos_on_non_migrated index -
[Feature flag] Rollout of container_registry_show_shortened_path
frontend -
docs(tooling): release tooling guide -
Automate creation of GDK version bump MR
Package Registry
For the Package Registry, we will focus on two things. First, we'll add the ability to bulk delete packages from the UI. This will help improve the usability and related SUS score for the Package stage. Second, we'll finish the settings
work required to roll out the Maven request forwarding feature. This feature will create new workflows for Maven/Gradle users.
-
Investigate: Incorrect statistics for packages -
Bulk delete packages from the UI SUSImpacting frontend -
Add pagination for Package "other versions" tab frontend -
Cascade package forward settings from admin area to group direction frontend
Community Contributions
Insert topic
Stretch goals
Container Registry
-
Serialization Error while performing Garbage Collection onboarding -
docs(database): setup local development guide -
test: remove testslowimport after phase 2 testing -
Dependency Proxy not falling back on timeout onboarding
Package Registry
-
Confidential issue -
Implement or properly deny npm audit
onboarding -
Maven sync worker: release xml node might be missing onboarding -
Don't display package details page for packages not in the default status onboarding frontend + backend -
Bulk delete UI for Other versions of Package customer frontend
Quality & quad-planningcomplete-action
Reviewed issues with actions:
Issue Refinement
Giving better hooks into registry events creates the opportunity for new user flows. For example, customers could kick off vulnerability scans on tag creation. This milestone, we'd like to refine the below issue.
Research
Issue | Deliverable |
---|---|
User survey | Record 3 customer interviews |