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
      • [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
Select a repo