Repo consolidation?

Historically, there was one repo for program management stuff: the poorly-named fedora-project-schedule. Because there was a lot of non-schedule stuff in that repo (and I’d planned on adding new things that didn’t exist, like docs), I created the fedora-pgm namespace with some repos like:

  • pgm_communication: for storing the Friday’s Fedora Facts and office hours info
  • pgm_docs: for the docs published to docs.fedoraproject.org
  • pgm_team: mostly for issues for our new team
  • change-management: scripts for processing change proposals
  • (etc)

I just created a repo for the schedule, since we’re moving away from using CVS internally (more on that later). I’d also like to just get rid of the old fedora-project-schedule repo in favor of an explict “elections-interviews” repo.

So now I’m starting to think I may have gone too far the other direction. Should some of these repos be consolidated?

pgm_communication and pgm_docs are obvious candidates for merging. The scripts I just moved into pgm_communication could be moved again into a pgm_scripts repo that also contains the contents of change-management.

The not-yet-in-existence elections-interviews repo should remain separate, since it will need to have different ACLs than the other repos. And the pgm_team repo makes sense to keep separate as a “front door” of sorts for the team. Or we could keep having many small repos with a single purpose.

What do you think?

1 Like

When I read this first time I was thinking about approach with separating tools like scripts from content like communication we send or documentation we write but then I realized that each repository has some tools so it can be hard to determine where is the boundary.
As Pgm probably our main work will be around:

  • Fedora release scheduling (scope, dependencies, timeline)
  • Change Management (all things related to change so list of changes with description, decision, impact etc.)
  • Various documentation (about products, maybe procedures, manuals), it will probably have the same format/structure per Fedora release so to reuse every 6 months with adjustments.
  • Constant and occasional communication (blog posts, mailings, regular updates to community or teams)
  • Tools (every scripts, packages that we use but are not part of above categories can be here but crucial will be good description how to use each of them and what is purpose of each tool, maybe one directory per tool and inside README.md)

So for now I count 5 repos and I’m not convinced about merging communication with docs but maybe I don’t see similarity yet.

The Changes content doesn’t live in our repos, just some tooling, so this probably doesn’t need to be a separate repo.

The main benefit I see to keeping these separate is to reduce the size. But neither of them are particularly large either:

bcotton@fpgm ~/f/pgm> du -sh pgm_communication pgm_docs
13M     pgm_communication
6.2M    pgm_docs

My main concern with having too many repos is that it becomes harder for us to remember where a particular thing is and for people to file bugs against our various work. The question is “how many is too many?” I think with the elimination of the change management entry (putting it in tools) and maybe a consolidation of docs and other comms, your suggestion makes good sense. It’s at least closely in line with what we have now. :slight_smile:

What we keep in current repos except various tools for particular purposes? Do have there also content or content land somewhere else as outcome from using those tools?
Now I have doubts if I understood correctly what is there :slight_smile:

I welcome you to look at the repos and see. :slight_smile:

I looked at this again and honestly until I start using them it’s guessing :wink:
Now I don’t have any strong feelings about the direction.

1 Like

FWIW, my leaning is towards more granularity. I think it might help me to tune the signal-to-noise ratio a bit in my email. If anything I think pgm_communication sounds too broad. In particular, I’m thinking that if there were a pgm_interviews, I would unfollow it. :stuck_out_tongue:

I’m assuming that I might still be able to access the repo history through its web interface even if I’m not following a particular repo?

Okay, so the general consensus seems to be that we want to be pretty granular. I think we’ll go with this plan, which I’ll start putting in place on Monday unless someone is like “OMG NO YOU CANNOT DO THIS”

  • keep the pgm_communication repo as-is
  • keep the schedule repo as-is
  • keep the pgm_docs repo as-is
  • keep the pgm_team repo as-is
  • create a pgm_scripts repo with the scripts from pgm_communication and changes_process
  • create an elections_interviews repo for elections interviews
  • retire the old fedora-project-schedule repo
  • (update the docs for all of that)

This seems to reflect the input from Pawel and Gregory and match with how I’ve actually used these repos over the last three years. And of course, we can always make changes later.

This is done, except for retiring the old fedora-project-schedule repo because I’m going to use it to show a few features in the Pagure training.

1 Like