# PulpCon 2020 planning doc

###### tags: `PulpCon 2020`

---
# **VOTING FOR TOPICS IS CLOSED! Thanks everyone for participation.**

---

## Goals
* pair programming / review sessions +1
* asciinema demos
* Team bonding - social time, maybe a game, or walk/exercise break up long meetings? Smaller group activities?

## Topics

* Development Environment Workshop +1
* Using pulplift effectively
* What other coding tools are core pulp developers using every day?
* What docs does one really need to read to work on pulp?
* Ties in with the community and state of plugins topic.
* If everyone can share one tool or trick or process they use that resulted in an efficiency boost, we could perhaps produce a useful cheatsheet.
* fzf, ripgrep, fd, ncdu
*
* State of plugins (a candidate for the community session)
* No new plugins have been developed in 2020. Last new plugin pulp_npm started at the end of 2019.
* "By us", do we know that nobody in the community has written one? We're too overburdened right now with what we have on our plate to commit ourselves.
* How can we improve this?
* How can we better encourage and support our community to develop new plugins?
* ~~4.0.0 release planning~~ Major Release Branching +1 +1 +1 +1 +1
* [bmbouter] Interested mostly in answering: how do we facilitate development of 4.0.0 while at the same time active development on 3.y.
* Renamed to "Major Release Branching" to avoid talk about 4.0 features
* Lockless pulp
* Our aproach to locking on resources forces us to live in the so called synchronization quadrant. Are there ways to get out of it?
* Can we remove the need for the resource manager?
* Installers +1 +1
* pulp_installer x single container x pulplift x pulp-operator
* how to make it less complex and confusing?
* Unifying installer documentation (IMHO plugin doc should not contain much more than a reference to the pulpcore installation doc)
* Community +1 +1 +1
* Where are the community PRs? How to make the PR process easier for the contributors?
* pulplift is not easy and practical (docker seems more friendly to a casual contributor, setting vagrant and an entire VM just for one or two PRs discourages the contributors)
* The [noissue] thing always make contributors PRs to fail
* [noissue], flake8, black, ... it can make the contributor push so many times, before actually seeing the PR being really tested
* https://pulp.plan.io/issues/6938
* [bk] I would like to see community broken down into "How do we get more users" in addition to "Make it better for contributors". I think pulp needs more exposure and users.
* Are mailing lists ideal? Should we move towards a more modern form of community engagement
* A lot of the conversations happen on Freenode #pulp-dev while there is a #pulp channel for general questions. A lot of the general back-and-forth of the Pulp team could be considered lost to general Pulp users.
* Would moving to something like Discourse be an idea for all development and community chatter?
* Recap of the relative_path proposals +1 +1
* Review and look at the pros/cons of the proposals so far for the relative_path problem
* multi-tenancy +1 +1
* How can we ensure users who don't trust each other can't access content from other users
* e.g. one user has a RHEL subscription and another doesn't
* e.g. one user uploads a sensitive RPM and another user adds it into their repo
* Pulp CI architecture +1 +1 +1
* Problem: our CI is a mishmash of pieces cobbled together through incremental changes over the past few years
* Goals:
* Redesign our CI architecture to make it not Travis-specific (for move to Github Actions)
* Make it so devs can easily run it from inside pulplift
* Make it pluggable or easier to add new functionality/checks
* Have a way to automatically update repos when there are changes
* Pulp 3 CLI design +1 +1 +1 +1
* Discuss latest design ideas based on recent squeezer work
* Use cases from community +1
* Allocate a slot or two on the schedule for users and stakeholders to share their use cases and see how we can address their needs
* Motivating and perceptions for a UI for Pulp +1
* [bmbouter] believes that not having a UI is significantly holding back the growth of the Pulp community