A few tasks in quick-docs requiring admin access

Hi folks,

Could someone from the quick-docs pagure group that has admin access to the quick-docs repo please take care of the following when convenient:

  • change the primary branch for the quick docs repo from master to main (this also requires updates to the deployment scripts from what I remember). ticket for this here.
  • maybe protect the main branch so that all contributions are made only through PRs (no direct pushes)? This will allow us to quite freely add lots of community folks to the quick docs committers group so that more folks can write/review/organise the repo.



Renaming the master branch is probably not the most urgent action, but the current naming is odd and outdated.

@pbokoc you are the maintainer and know the deployment chain, please could you take care of this?

We should configure this repo the same way as our GitLab repos. So it is fedora-docs-admin with admin and commit privileges, not fedora-docs.

Regarding to protect the main branch: we have just one branch. So we would have to handle the quick-docs-committers group. If I understand you correctly, we should make it to a quick-docs-noncommitters group. Might be better to fix the group members?

In the last 6 months we had commits by:
Active contributors were:
ankursinha (quick-docs-committers, most active)
Anthony McGlone, (quick-docs-committers)
Micah Abbott (quick-docs-committers)
Simo Sutela
Kamil Páral (quick-docs-committers)
Weverton Timoteo
Petr Menšík
HĂ©ctor H. Louzao Pozueco
Flo H
Taisei Washington
Zdenek Dohnal (quick-docs-committers)
Timothée Ravier (quick-docs-committers)
Devin Prater
Jun Aruga
Ooyama Yosiyuki
Felix Schwarz (quick-docs-committers)

I’m not sure if it is a good idea to de-privilege active contributors. On the other hand, we need at least some communication to coordinate the efforts.

Maybe we should start with withdrawing members who have not contributed in the last 12 months? And try to establish a communication before we change privileges of active contributors?

1 Like

Ah. No. I meant that we enable the setting in the repo so that no direct commits can be made to the main branches at all. Everything must go through a PR, which means everyone subscribed to the group—committers and admins—get a chance to review/comment on a change before it goes through.

I believe in Pagure, one goes to settings > project options > check “pull request access only”. (I think GitHub has this feature too, but I haven’t looked at GitLab—it should)

and then this pops up on the repo page: “This project does not support direct push to its git repo, all changes must be done via pull-requests from forks”

If we enable this, we can have as many committers as we want and we must all open pull requests. Pull requests should be the norm anyway, just so that everyone is notified of any updates and has a chance to comment. We shouldn’t push directly (although even I’ve done it a few times for minor tweaks). This will enforce the PR workflow.

We could, but regularly cleaning up privileges is also extra work that we perhaps don’t want to take on unless absolutely necessary?

1 Like

OK, I understand. And I think that’s really worthwhile a goal, especially for Quick Docs, which has a very broad range of topics.

But given the decidedly unsatisfactory state of the repo, we should avoid abrupt change at the moment. We need a transition path to the goal. The most important thing is to find a way of organizing and working that prevents a PR from lying around unprocessed for almost a year or even longer. We then scare away any contributor, no matter how well-meaning they are.

I would like to discuss that in an extra thread.

1 Like

This, unfortunately, is the usual resource constraint problem that we constantly fight with. Not enough folks are helping out with the quick docs. I try to:

  • fix issues that I can manage myself
  • merge small changes that I can check myself
  • post on the -devel list asking for help when it’s something that needs a specialist
  • when we do get a specialist, I add them to the committers group so they can keep the page they care about up to date (Zdenek has taken over the printing docs, for example: Commits - fedora-docs/quick-docs - Pagure.io)

So, we need to find ways of getting more people involved in docs—we’re already seeing more contributors now with all the activity that’s happening here, so I’m very optimistic about more folks from the community helping with docs.

1 Like
  1. I agree we should move to main, but I’ll let someone else take care of that since I don’t know exactly what needs to change in the deploy script
  2. I’m not actually sure how to do this in pagure. (I know how to do it on GitLab, fwiw.)
  3. If anyone else should have admin access, I’m happy to hand it to them, because I shouldn’t be a blocker here!
1 Like

I can do changes in the repo (main + pr only), but do not have access to deploy scripts. Last I recall Ben had access to those.

Hi copperi, I agree, Ben does have access and should know everything about the deploy scripts as well. At least, he helped with the deployment of our Server WG pages. If you could manage to get it done with him, would be really great.

Regarding PRs. Some PRs need clarification some are OK.

I checked the open PRs

#372 and #488 are OK contentwise as they are. They are quite old and cause probably issues in GIT, that I may not be able to resolve due to limited GIT skills. So, if you could try to pull them, would be great! Just in case of content questions i can contribure.

#423. #428,#429, #467, #431 modify the same files as far as I can see. The modification in each file seem to be OK for me, but the cumulated result? I suppose the only way to find out is to pull them locally step-by-step and to check the result.

If you could do that, too, would be even greater.

#313 is about some obviously old stuff. I can’t make any sense of it. Ben was involved and might remember. If you could decide with him how to deal with it sensibly would be great. And if we decide just to close the PR, we should provide a good reason in the comment. In any case, we should pay respect to the work done. It’s not the contributor’s fault that this has dragged on until now. I find something like this extremely unfortunate.

#411 is about commands regarding custom kernel, 1 year old. The last time i compiled a kernel was about 10 years ago, or something like that. Do you have the experience for a short check of the content? Otherwise, we can try to contact jforbes to modify the text that it makes sense.


The deploy part is here, you just need to add the branches: main part to it once the repository has been changed.
I can take care of that over the weekend if you want.


I handled some of the open PRs; current status:
#372 merged

#423 merged
#428 closed (no changes after #423 merge)
#429 closed (no changes after #423 merge)
#431 closed (no changes after #423 merge)

#313 has unresolved conflicts
#488 has unresolved conflicts

#411 Have to look closer.


Many thanks for your efforts. I resolved the two merge issues manually, That was the easiest way.

Would be really helpful if you could take a closer look on #411!

@darknao Could you take a quick look at issue #528 when you get a chance and check if we really need all the Antora instructions that are there especially at the beginning? I suspect most of it is superfluous.