# Planned work and estimates

Timeframe: July - September 2020

## Goals
* How much work do we already have to do over the next three months?
* Is there space for new initiatives?
* Where does everyone fit into this set of work?
* [ttereshc, Jul 3] When we decide what to drop, I believe it's important to know who can/will work on what. E.g. if I have time and pulp-operator work requires a lot of FTE, I can't help there with the same efficiency as the estimation implied (I'd need time to get up to speed, have knowledge transfer and gain more familiarity with this topic in general).

## Definition
* FTE == 40h*Employee/Week (and includes planning, non-coding feature work)
* "Feature Work" estimates include tests and docs
* Only use quarter points (.0, 0.25, 0.5, 0.75)
* Estimating .5 or .6 per person ... roughly 40 - 50% overhead
* add stakeholders/dates

## Number of FTEs

* 12 developers * 3 FTE/m = 36 * .5/.6
* 18-21 FTE
* Estimates are 28.25 FTE * mo
* Can we shorten miniteam meetings to 30 min until October?
* Increase FTE per person to .7-.75?
* 36 * .7 = ~25
* If shorten mtgs, modify mtg-schedule to have mtgs line up into blocks

## Pulpcore & pulp_file (10)

* Import/export - 1 FTEs for 1.5 months
* Includes RPM work
* Import/export for any plugins other than file & RPM not included
* RBAC work - 0.5 FTE 2 months
* known katello features 0.25 FTE (katello tag) - 2 month
* includes logging feature
* [INVESTIGATE] relative_path problem - 1.5 FTE for 3 months
* lots of planning/discussion to get to the right answer
* [ttereshc, Jul 3] I'd like to postpone this effort however I'm not entirely sure that we can do it. Mirrored metadata feature is important for Capsules workflow, and there were reasons why it would be much better to have it in Katello 4.0. There are either some complications for the upgrade, or just many customers won't upgrade to the productized Katello 4.0 and will wait till the feature is ready. Maybe dkliban recalls the details? Before dropping this item, I suggest to discuss with Katello consequences of delaying the feature. Sean was also reminding that they need it and some large customers are expecting it.
* Question: What about FIPS? (or maybe this goes under ansible?) .5FTE for 2 months?
* also Much Planning, So FIPS, wow
* what about other plugins? RPM will be done later (next quarter)
* Move to openapi v3 - 1.5 FTE
* replace drf-yasg with drf-spectacular (pulpcore and all plugins) - https://pulp.plan.io/issues/7108
* test all plugins
* introduce new tests to test the FileField issue (maybe introduce more scenarios)
* (1 * 1.5) + (.5 * 2) + (.25 * 2) + (1.5 * 3) + (.5 * 2) = 10 FTE * mo

## CI/CD (2.75)
* Release pipeline (1.25 FTEs for 1 months)
* [CANDIDATE] Upgrade testing (1.5 FTEs for 1 months)
* use pulp_file to have upgrade-tests as part of release-pipeline
* including migration of data
* [ttereshc, Jul 3] I'm the one who really wants it to be done. But we live without it now. If we drop it, maybe it's worth adding a step to a release process to identify potentially risky areas and if there are any, manually test the upgrade before the release is going out. It's not efficient long-term but likely less LOE than 1.5 FTE/month for July-September.
* (1.25 * 1) + (1.5 * 1) = 2.75 FTE * mo

## Installer (3)

* [INVESTIGATE] pulp-operator 1 FTE for 2.5 months
* publish on operator hub [(Epic)](https://pulp.plan.io/issues/5132)
* able to deploy with external postgresql
* able to deploy with S3 or other object storage
* Upgrade single container to centos 8 (0.25 FTE for 1 month)
* SELinux integration into the installer - .25 FTE for 1 month
* (1 * 2.5) + (1 * .25) + (.25 * 1) = 3 FTE * mo
* [rchan 6-Jul] Perhaps this is an area we can ask for help from contributors or other teams?

## Pulp Container (4)

3 months planning: starting from July (1.5 FTE for 3 months)
* [CANDIDATE] import/export work (.5 FTE/mo?)
* RBAC work
* Work for 2.0 milestone https://tinyurl.com/ya4t993x
* [ALREADY DONE?] Performance work
* (1.5 FTE * 3 mo) = 4.5 FTE * mo

## Pulp Ansible (.5)

* Token content protection implementation - 0.25 FTE for 1 month
* RBAC additions - 0.25 FTE for 1 month
* (.25 * 1) + (.25 * 1) = .5 FTE * mo

## Pulp Python (1)

* Bandersnatch integration (includes contributions to Bandersnatch) - 1 FTE for 1 month

## Pulp RPM (1.75)

Total: 1.75 FTE for 1 month, excluding performance work and mirrored metadata
* mirrored metadata (included in relative_path problem in the core)
* [CANDIDATE] RBAC - 0.25 FTE for 1 month
* [ttereshc, Jul 3] It's not needed for any product at the moment but it has a great benefit for community. I suggest to keep it, the benefit vs time investment ratio makes it worth, imo.
* [rchan 6-Jul] Can it be pushed to next quarter?
* [CANDIDATE] zchunk support - 0.5 FTE for 1 month (can be deprioritized)
* [ttereshc, Jul 3] Again the improved user experience for both community and Satellite. Before dropping it, it might be worth to spend an hour or so to evaluate if there is a lot to do. If the tooling is zchunk ready, then it's a noticeably smaller effort for Pulp RPM and not worth dropping in such case.
* [rchan 6-Jul] We have to do work in Pulp 3 to ignore zchunk or support it? Is that the choice - or is it a matter of timing?
* known bugs as of now - 1 FTE for 1 month
* [ttereshc, Jul 3] I don't think there is much to reduce here. It's either a katello need, or quite nasty bugs affecting users. Maybe 0.75 and not 1 if it helps and someone is working on it efficiently.
* potentially performance work (not included in estimate yet)
* (.25 * 1) + (.5 * 1) + (1 * 1)

## Pulp 2to3 Migration (3.75)
Total: 3.75 FTE for 1 month, excluding performance work

* minor features (0.25 FTE for 1 month)
* [ttereshc, Jul 3] I looked at the list of feaures closer and reduced the LOE a bit (adjusted all respective numbers). All are essential for katello, except one feature - executing a simple migration plan in parallel (aka generate complex migration from a simple one). Not a huge amount of work but an obstacle for pulp upstream community to migrate comfortably to pulp 3.
* known bugs as of now (0.5 FTE for 1 month)
* [ttereshc, Jul 3] nothing to reduce here, working on critical items only.
* tests (1.5 FTE for 2 months)
* [ttereshc, Jul 3] I'm not comfortable dropping this item completely. If we decide to drop it, then we should increase LOE for fixing bugs/regressions. However, we can reduce the number of FTE a bit and commit to cover main critical paths and collaborate with QE so they test in Robotello more corner cases and complex Katello migration plans. There is still planning to do as well as to create some base for just adding tests, so we can maybe drop 40% of proposed LOE to focus on main paths and, especially, if QE is willing to collaborate and test things in Robotello in the July-September timeframe.
* likely performance work
* (.25 * 1) + (.5 * 1) + (1.5 * 2) = 3.75 FTE * mo

## Pulp 2 (1)

* .333 FTE for 3 months

-------------------------------
# Not planned work but usually takes time

How we will proceed with bugs and stakeholder requests?
https://en.wikipedia.org/wiki/Factor_of_safety

* All regular meetings (e.g. for july-september - 1 ttereshc for 2 weeks)
* 8(ish) hours/wk just for regular mtgs
* PTO :)

## Installer
* bugfixes and improvements for galaxy

## Pulp Ansible
* galaxy requests

## CI/CD
* debug CI failures

## Satellite
* Support and Planning

## Process discussions
* backporting
* sprint process revisions