Move docs sources and issues to GitHub, redirect subdomain to spins website

Hi everyone,

We’ve had several contributors ask to move to GitHub or Gitlab as they find Pagure hard to use. Unless there is a concerted effort to improve the areas where Pagure is lacking, I propose to move the issues and docs sources to GitHub. It would then look like this: Fedora Silverblue · GitHub

The issues were initially put on Pagure because there was too much pushback to have them on GitHub. Fedora’s new strategy also means it is easier to use those building blocks that make sense and not use those that don’t.

This would mean that issues, docs, and website are all in one place. Other than that, there is only Twitter, IRC, and this forum which makes it easy to find things rather than have them scattered. Further down the line, when the website team has time to pick it up, the website should be just a redirect to a Silverblue section on https://spins.fedoraproject.org/. On that spin site, there should be just be links to the Discourse forum, an introduction to what Silverblue is, the docs link, and additional static resource links. The documentation is where the explanations should happen.

The long-term proposal is as follows:

  • have docs and issues on GitHub to make it easy to use and discoverable, contributors benefit from a boost in their GitHub profile
  • have the subdomain redirected to a Silverblue section on Fedora spins once the website team can pick it up (this ensures that the download links will always be up-to-date)

The documentation continues to live on the official Fedora documentation, only the source will be on GitHub. This also makes it easier for new people who do not have solid git knowledge to contribute to the documentation as most git tutorials cover GitHub whereas Pagure has an additional learning curve on its own due to its unfamiliar UX and missing features.

Please vote in this poll only if you are interested in using Silverblue, already using it, and/or intend to contribute to the documentation or issue tracking.

Thanks!

  • move docs and issues to GitHub
  • stay on Pagure with docs and issues

0 voters

1 Like

Do you have some tickets opened against Overview - pagure - Pagure.io to track the improvement needed ? Or a list of what is currently making pagure hard to use ?

Pagure has now a monthly stakeholder meeting where issues are prioritized and planned against releases so it might interesting for some silverblue folks to join

2 Likes

I have a list - sent it to you via email just now.

Three of the main issues are:

  • can’t rename projects (projects mature or change focus and often change name along with it, for example we could not name the project Fedora Silverblue straight away but had to do things gradually, hence we had a Team Silverblue first)

  • search bar is laggy/buggy

  • can’t do merge conflict resolution via UI

Definitely interesting to join in the stakeholder meeting, thanks for the link.

1 Like

Hello,

Speaking for myself, I have run into some difficulty with Pagure while I am trying to commit to the Documentation for Silverblue. As a long time Fedora user, and someone who wants to contribute to the Silverblue project, I will say that I use git minimally in my day to day work. When I do I never run into the issues I do with Commit/PR/Merge cycle that I have had with Pagure the last couple of commits I did. I would likely vote for GitHub based solely on that experience. There is also another discussion around Pagure that @blaise was involved in. There he had talked with the Pagure developer (not certain of the individuals name) about how the project was using it, and what resulted was some interesting discussions around the correct use of Pagure. Perhaps GitHub is the better solution, but I would hate to vote something good out of the mix for only the reason of not understanding how to use the technology correctly.

1 Like

This tracked by Issue #2103: Allow renaming a repository - pagure - Pagure.io

There are quite a few tickets for that

I don’t think that there is currently a request for that, I ll double check with pingou so we can start tracking it.

I think overall for these to happen you need someone to push for it to be included in the roadmap :slight_smile:

2 Likes

Yes, that’s the issue - it’d basically need a product owner on its case.

The same issue is with Silverblue - if there was a dedicated team and a product owner, sure it would be different and ready by now. But everyone working on Silverblue does it via a chunk of their own time and some things happen as a nice side effect, like Flatpak improving where Silverblue benefits from it, etc. The CoreOS team of course does a lot of things for rpm-ostree and that’s what Silverblue is based on, so, yes Silverblue is being worked on but it’s not a straightforward process where you can just file a ticket and then things are just taken care of.

One of the outstanding issues with pagure I keep running into is the lack of code search in the web UI:

https://pagure.io/pagure/issue/539

Sometimes I want to do a quick search of the repo and not have to git pull it to search locally. This kind of UI omission is pretty glaring when compared to GitHub or GitLab.

2 Likes

Actually, I was referring to Antora. I do have some suggestions for Pagure, which I have discussed in the CommOps team meeting and I will write those up shortly.

Sorry, I thought it was about Pagure.

A big thumbs up for moving to GitHub - I like GitLab’s way of doing CI a bit better, but the discoverability of GitHub projects is so much better than GitLab projects, so GitHub it is. :wink:

1 Like

I think moving core Fedora resources to third-party proprietary infrastructure owned by Microsoft is an absolutely horrible idea. It is essential for a major Free Software project to control its infrastructure and to use Free Software in it.

I also take offense at your voting instructions:

Please vote in this poll only if you are interested in using Silverblue, already using it, and/or intend to contribute to the documentation or issue tracking.

I think the infrastructure used for subprojects that want to be part of Fedora is a matter that affects the project as a whole and not just your subproject. Having Fedora documentation scattered to several third-party hosts depending on the personal preferences of the subproject is not user-friendly, raises the barrier for your contributors to also contribute to Fedora documentation outside of your subproject, and renders Fedora as a whole dependent on random third-party infrastructure.

A lot of major OSS projects are already on GitHub (e.g. systemd), as are several Silverblue core components (ostree, rpm-ostree, Flatpak, …). Regardless of reasons for or against this, I think the ship for this argument has largely sailed.

1 Like

The priority after the acquisition of GitHub by Microsoft ought to be to move everything away from GitHub, not to move more stuff to it! Especially for things such as rpm-ostree, this should be well under the control of Fedora or Red Hat, and there needs to be a push to migrate those upstream projects off GitHub as soon as possible.

In addition, the projects you listed are upstream projects, which is not the same as moving the documentation and the issue tracker for a part of Fedora itself (the Silverblue subproject) to GitHub. So I do not think that this is a valid precedent.

2 Likes

IMHO, the root cause is that pagure needs improvement:

  • better U/X (search, workflow)
  • wider client support (GUI clients, Mobile browsing)

True, git is tricky for those of us old enough to have learned a file system VCS first, but Github doesn’t make it much easier.

I get the impression that some Fedora apps get to a point where the first gen power users get familiar and then progress stops.
I also notice that these apps lack feedback loops for the user interaction.

For example, I create:
https://pagure.io/fedora-docs/docs-fp-o/issue/104
butI can’t flag it as a feature request, I can’t assign it to anyone, in fact I can’t edit any of the metadata even though I created the issue.
OK, no problem, I’m sure there is a workflow where orphan tickets get flagged.
hmmm, maybe not.
Two weeks later, no change in status whatsoever.

To get meta, I just opened: [a RFE asking for guidance on how to provide feedback]Issue #4125: [RFE] Expand the README to include "How to provide feedback" - pagure - Pagure.io) and I noticed that there is no way to edit the meta data, nor assign it to anyone.

I don’t think moving to Github is a solution because their workflow tools are hardly much better.


In some respects, the M$OFT ownership is a red herring.

  • We are Fedora, for crying out loud. We should be leading community by showing what is possible.
  • Ostensibly, the whole point of moving to Antora was because of its repo-independent, multi-project architecture (I’m still a skeptic on Antora), Github has terrible cross-project integration.
  • We should be capable of adding features and integrating our apps.
1 Like

If Git tutorials attempt to cover GitHub, they should not be considered Git
tutorials at all, but GitHub advertisements, and should be disregarded as
such.

1 Like

This is a build-or-buy decision. Usually, the correct choice in a build-or-buy decision is, “If we will earn revenue on what we’re building, build. Otherwise, buy.” :wink:

So yeah, if IBM wants to get into the repository hosting business and decides to buy GitLab, sure, move everything to GitLab. But if the choice is “build a repository hosting / issue tracking system just for our own use,” no - you buy it.

1 Like

Is it? I disagree and the new Fedora strategy disagrees as well. We’re not bound to the building blocks Fedora provides, just because they’re there. They are blocking us if anything. Also, that means that any Free Software Project is going to struggle because having to control your own infrastructure means way more overhead than just focusing on your actual solution.

rpm-ostree is unlikely to move to Pagure. CoreOS, buildah, and podman for sure won’t move to Pagure. The same people who work on one work on the other. The people pushing for innovation in the container world contribute to wider communities like Kubernetes and other solutions. I’m sorry you take offense at my voting instructions, I’m not blocking anyone from voting and using the Fedora forum for it - so chances are heavy Pagure users will get offended and vote for Pagure despite never showing interest in Silverblue. I take the chance anyway because I have been approached by enough community members who want to move away from Pagure and if this poll shows us that GitHub is clearly more favored than Pagure, there is nothing to add.

We want to focus on a solution - which is Silverblue, an rpm-ostree-based container-focused desktop. There are many Fedora-external contributors and forcing them to do things on Pagure alienates them. Silverblue comes from Fedora Atomic Workstation, Project Atomic was not as such part of Fedora. We want the community to grow. People who really want to contribute to the wider Fedora documentation will do so, but it’s likely they’ll just as much want to contribute to Containers · GitHub or rpm-ostree or CoreOS.

That said, I fully agree with @znmeb.

A major motivator is to make Silverblue big enough so it cannot be ignored by the end of next year. Will we do that if we stay on Pagure? No. Will we do that if we go to GitHub (or Gitlab)? Maybe. At least there’s a bigger chance. I’d also favor Gitlab just because I personally like it, but it doesn’t make sense to put it in this mix now because now it’s a question of people getting offended at the move away from Pagure.

Once the argument over that is settled with a vote outcome, we can think of GitHub or Gitlab - there should be less tension around that, so a vote on GitHub vs Gitlab makes more sense. Diluting the poll now with 3 choices doesn’t make sense. So let’s talk about GitHub vs Gitlab in the next iteration right after this vote.

GUI clients are a git issue, not really specific to the specific git hosting service used.

I have found git-cola and QGit to work well for me. But either way, you will use the same tools no matter what hosting platform your git repositories are on.

“build-or-buy decision” is corporate speech. Fedora is not a company, it is a Free Software project.

IBM does not have any say in Fedora as long as its acquisition of Red Hat is not finalized. Until that happens, Red Hat is still a separate entity. But Fedora is not a pure Red Hat company project either, so you cannot apply corporate logic as is.

In the Free Software world, independence from third parties and especially from proprietary software is an important decision factor that you cannot just ignore.

In addition, Pagure was already built, mostly by volunteer developers. So throwing it away now in favor of a third-party component does not make sense in a “build-or-buy” context. (That said, Pagure is not going to be thrown away either way, you just want to move one project from one existing hosting platform to another. The issue is that you are giving up independence and freedom with that move.)