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


#21

The new Fedora strategy does not say anything about hosting infrastructure.

Please note that I clearly talked only about major Free Software projects. It is reasonable for small projects with limited resources to depend on third-party infrastructure (though Free Software should always be preferred), but projects of the size of Fedora should really be, and are in fact, able to host their own infrastructure. Silverblue by itself is a small project, but it is part of the larger Fedora umbrella and hence should make use of its infrastructure.

For a small project that cannot host its own infrastructure, Free Software should be preferred, so Pagure (even for non-Red-Hat projects) or at least GitLab (though that one is crippleware) would be better places to host them on than the entirely proprietary GitHub. Sometimes, there are technical limitations restricting the possible choices, e.g., I have to host the Kannolo ISOs on SourceForge because they are the only hosting service that accepts 1 GiB ISOs (mirroring them myself is impractical because the bandwidth requirement could grow indefinitely if it becomes popular), but I use a self-hosted Subversion and ViewVC installation (rather than SourceForge’s SCM integration) and Copr (for package building) as the main infrastructure, I use SourceForge only to distribute ISOs.

If these projects are controlled by Red Hat, Red Hat should move them to infrastructure it controls. Canonical is doing that very aggressively, imposing Launchpad for all its projects, a move that also spreads the use of Launchpad (which is sadly proprietary). So why not do the same for Pagure? But of course I have no say whatsoever in Red Hat decisions, I don’t even work for Red Hat.

I think it makes a big difference whether we are talking about moving to a semi-Free solution with a crippleware Community Edition (GitLab) or to an entirely proprietary solution owned by Microsoft (GitHub).


#22

You are correct, however I have used it all these years since it’s inception and it has always had the pains of been “owned” by Red Hat. This is a common thread of discussion through the community stretching back to the early 90’s. What this vote was about is likely my very example of the document I am trying to continue fleshing out for Silverblue, but have run into some issues with doing simple commits to the site, that I can perform flawlessly on a normal git repo. While I’ll admit freely I am not a git guru or even a power user of it, I can figure out how to properly commit/PR/Merge etc… and Pagure makes that a relatively painful process for some reason. The fact that MS is owner of Github should cause us to look at using a community based repository hosting service, but that again is a separate discussion. Fedora is not technically a Free Software project, it is an Open Source project. Although it uses GNU/Linux, it does not meet the FSF requirements to be a sanctioned free Distro. The issue around the move of documentation sources for Silverblue to a more usable place is the issue. It is about lowering barriers to community involvement, and trying to engage more of the community in projects related to it, such as documentation which is crucial to those using it.


#23

Hey all,

I was leading with other people the evaluation of a full development platform replacement for GNOME, and the eventual transition to it (and help other projects with their evaluation too such as Freedesktop and KDE).

As much as I admire what Pagure and what its developers had achieved, in our evaluation Pagure was turned down quite in the early phases. It’s hard to compete with what the rest of the world has to offer, such as GitHub, GitLab, Phabricator (not anymore though), etc. There is a big amount of gaps that current developers just expect them to be there ootb. And this is key to drive contributions, specially for new members.

@kkofler as much as I appreciate that sentiment, if we want to do effective development and bring new contributors, we need to get to equal footing to other platforms. Limiting ourselves at the infrastructure level doesn’t help with the actual project.

Your point about free software is indeed a very valid concern, but it’s up to us to provide a competing solution at the Fedora level. For that, I believe a hosted GitLab CE would be a good solution, but this needs work to be done.

Let me know if you have any questions about GitLab if it’s eventually considered, I definitely will be glad to have one at Fedora level for my own work!

edit: Added the link to the study we did at GNOME.


#24

have run into some issues with doing simple commits to the site, that I can
perform flawlessly on a normal git repo.

Pagure repositories are just regular Git repos. You can use git directly, or
most Git GUIs to manipulate your local repository and push refs to the remote.

I can figure out how to properly commit/PR/Merge etc… and Pagure makes
that a relatively painful processfor some reason.

I don’t know about “PR”, but you can certainly commit and merge repositories
with remotes hosted on Pagure just as any other Git repository.

Fedora is not technically a Free Software
project, it is an Open Source project.

The very first of our Four Foundations, listed here https://
docs.fedoraproject.org/en-US/project/, is Freedom. In fact, the sentence
directly following that heading is “We are dedicated to free software and
content.”

Although it uses GNU/Linux, it does not meet the FSF requirements to be a
sanctioned free Distro.

Correct, because we have proprietary firmware in the repositories. There is so
little there that something so simple as https://git.splentity.com/millennium/rpms/millennium-freedom/blob/master/millennium-freedom.spec is considered to
meet the GNU FSDG.


#25

I thought the same thing of Pagure but have run into issue in use. I went to file a bug and found the same issue was a bug for some time with the last comment from 5 months ago from a user asking if it has been fixed yet. I didn’t file the report since I wasn’t going to add anything to the original which was quite detailed. I didn’t have any issue making the commits, I could happily do commits all day until the cows came home, but when I did a PR from the Pagure site for my commits, it seemed to break things. Meeting minutes from the Pagure team they published recently would seem to indicate a small group who are very busy with other things as well. So to me, it honestly makes little difference what the choice of version control and hosting is decided upon for the source content of the documentation as long as I can accomplish the task I have. If there is an already available ootb solution I am going to lean towards it if it is mature and has a dynamic support environment around it since it is simpler. That doesn’t negate the functionality of Pagure, nor does it give more credit to Github beyond what it can claim on it’s own merit. It just is the way I look at this particular problem. If the intent is to use Pagure moving forward then it needs a bit more love from the community to progress to the point of expectations I think.
I understand the distinction between the Fedora Foundations and the FSF requirements, as well as the razor thin disqualification. In the end it was and still is no more than picking nit’s and I didn’t participate in the drafting of the FSF requirements, or the documentation that was produced around the distinction between Free Software and Open Source. I was merely an observer of it and the end user of the resulting products.
The point of using Pagure moving forward for the Silverblue documentation or choosing to move to Github is what we need to determine collectively right now I think. If the collective decision is to stay with Pagure then like I say, it needs some attention to achieve the level of expectations that are being expressed. If that were the path, it is python code and though I am not as verse in it I would be willing to help, if only to solve the issue I am currently facing.
I must say for a Fedora representative, you’re not offering me much incentive to want to participate.


#26

FWIW, having the git repositories hosted in GitHub doesn’t bother me a lot — I’d rather an free and open source solution, but many free / open source projects are hosted there, and git is git. But I’m concerned about issues, for two reasons. First, that’s tying us in to a non-portable service. That’s a risk. Second, it puts us in a position of saying that to get help with some things, users need a Fedora account and for others they need a GitHub account. That’s kind of confusing. I’d like to see some kind of two-way mirroring bot at minimum.

@kkofler I think you’re vastly overestimating the resources we have at our disposal as a project. We’re having a lot of trouble getting things done which are unique to the project, and there’s a lot more we need to be doing to succeed that we’re just not able to get to. With that going on, doing infrastructure work which can be handled by someone else is painful.


#27

Hello @JohnMH,
I had a chat with @miabbott on freenode about git and we worked through what exactly my issue was. In this case it was not a Pagure issue, but a user issue. I now know what I did wrong to cause the errors I got when trying to perform a PR from Pagures site, and how to recover.


#28

I now know what I did wrong to cause the errors I got when trying to
perform a PR from Pagures site, and how to recover.

That’s great, I’m glad to hear it!


#29

FWIW, having the git repositories hosted in GitHub doesn’t bother me a lot — I’d rather an free and open source solution, but many free / open source projects are hosted there, and git is git. But I’m concerned about issues, for two reasons. First, that’s tying us in to a non-portable service. That’s a risk. Second, it puts us in a position of saying that to get help with some things, users need a Fedora account and for others they need a GitHub account. That’s kind of confusing. I’d like to see some kind of two-way mirroring bot at minimum.

+1 here

Hosting code is easy. Pull-requests, issues and userbase are a different thing. GitHub doesn’t provide the easy export for any of those. So what is going to be a long term strategy to keep the project data and users in case service provider decides to change its policy for its free service or simply disappear?


#30

Generally I understand the desire to make things easier and thus leaning towards tooling which gives you the initial comfort. But one of the reasons why we do Fedora is that we understand that comfort - is not all. There are other things and criteria which are important and need to be considered.

One of them - is being new, and forcing ourselves to get outside of our comfort zone to try new things. The other - is being responsible and caring about the big picture. We shouldn’t follow the next shiny thing around but should look into long-term consequences and effect of our decisions.

And while getting larger usebase and reach for the community is good, doing that by effectively selling our user base to a third party service which we have no control of - is not.

There are many ways to address the usability issues of Pagure. One is by actually addressing them. The other is look into alternatives, and there are many, not the GitHub alone.


#31

No, I disagree almost entirely with this sentiment. It’s entirely subjective,
but I’ll respond point-by-point regardless…

Generally I understand the desire to make things easier and thus leaning
towards tooling which gives you the initial comfort. But one of the reasons
why we do Fedora is that we understand that comfort - is not all. There are
other things and criteria which are important and need to be considered.

You can certainly have a comfortable environment in Fedora, that’s one of the
main reasons that I do use Fedora (or, rather, my own Remix, Millennium).

One of them - is being new, and forcing ourselves to get outside of our
comfort zone to try new things.

I couldn’t disagree more. It’s true that Fedora has a lot of things that are
“new” and “force [people] outside of [their] comfort zone”, like Modules.
However, none of these things are inherently a good thing, certainly not
Modules, which is the first example which came to mind.

The other - is being responsible and caring
about the big picture. We shouldn’t follow the next shiny thing around but
should look into long-term consequences and effect of our decisions.

And while getting larger usebase and reach for the community is good, doing
that by effectively selling our user base to a third party service which we
have no control of - is not.

While this is really a contradiction of the previous point, I could not agree
more with this statement. We shouldn’t just rush to go to the popular “hip”
tool, but rather weigh the consequences and make an informed decision.

There are many ways to address the usability issues of Pagure. One is by
actually addressing them. The other is look into alternatives, and there
are many, not the GitHub alone.

Certainly, and this seems to be a common idea with users, which is definitely
a good thing. Pagure has great potential, as a service formed by users’ needs.
Even if it is decided that Pagure is not the “best” option, one of the many
alternatives that we could give a try has already been mentioned here, GitLab
CE.


#32

While this is really a contradiction of the previous point

You are right. We are balancing between several different priorities which point to almost opposite directions trying to find the right spot: trying to be new, but to be stable enough, to be easy, but to be deep and flexible, to be comfortable but to be committed to our goals and principles.

And balancing is hard.

But that’s the point :slight_smile:


#33

If the decision were to go with GitHub, there maybe just be automated backups of issues via the web API. Assuming that there’s a bot linking both Fedora and GitHub accounts together, it’d be easy to move that around.

FWIW CPython had a rather successful GitHub migration, and they use a bot to e.g. check the CLA signature and ensure the BPO and GitHub accounts are linked.


#34

Even with this kind of backup, it is still essentially a lock-in on GitHub environment, including CI, project structure, tagging, groups, permissions, roadmaps,… whatever else GitHub provides. And you still bring your user base to GitHub, rather than bring GitHub user base to you.

If you look how Openstack does it, they do it the opposite way: they mirror Git repos to GitHub, which provides a nice overview, full text search, diffs, history and discoverability. But they keep these GitHub repositories in a read only mode. And they keep the development, pull-requests, issues, CI and project management outside of it.

Because these are the things which grow almost uncontrollably on top of initial code base you have started. Some small bots to do bug transitions, tiny scripts to perform validations, configuration here and there to do your notifications and some reporting tools, which do analysis for you… They grow to become enormous set of features, custom tweaks and adjustments.

These things are extremely hard to migrate once they are set up and configured. And this is exactly what ties you to a certain infrastructure forever.


#35

Fedora and SuSE are tied to .rpm forever, Debian and Ubuntu are tied to .deb forever. Both seem to be doing just fine. So do Gentoo and Arch. :wink:

Seriously, there are things Fedora can and should re-invent. I think Silverblue is one of them - a workstation for container native development.

I don’t think CI/CD/version control/issue tracking/mini-Kanban source development is one of them unless Fedora can earn revenue because “the Fedora way” has a compelling advantage over GitHub’s to paying customers. If IBM / Red Hat want to offer Pagure to customers, let them say so. Otherwise, let’s move to GitHub, or have a bake-off between GitHub-, Altassian- and GitLab-hosted repositories.


#36

Sorry, but I can not get your logic.

First of all there is a huge difference between building a project on top of a certain open source technology, and locking in to a proprietary third-party service provider. This kind of analogy simply doesn’t work.

Secondly, your revenue argument is not applicable to this discussion. Fedora is not built for revenue, it is built for open-source innovation. And this innovation is not limited to the Silverblue effort.

While the infrastructure resources we use are less hyped maybe, and don’t always look as shiny, but we do things which no one have done before. And being the driver for adoption of open-source tooling on the infrastructure level is as important as taking over the developer workstation.

And we are not reinventing things here, we are creating new.

I would rather see some understanding from community members and maybe thoughts and ideas how we can improve the situation.

For example Pagure developers can prioritize the issues for their roadmap, and generic Fedora audience including Silverblue SIG can help with promoting, writing those tutorials, onboarding newcomers and building a healthy community around Pagure.

Or at least Gitlab if it comes to this.

The other point is that generally we should start actively searching for contributors to Fedora Infra. We have many interesting tasks there, for both juniors and seniors alike. With technologies like Ansible and Kubernetes and with that scale we have, we do a lot of unique and quite fancy infra stuff, which we don’t usually brag about. And we should probably start doing it :slight_smile:

So please remember that we are the big platform, and big community united by common values. And if slight annoyance in your personal workflow can help others to build a better thing and avoid a proprietary lock in, may be it is worth it.


#37

I would say that you would be hard pressed to find anyone in the Fedora community of users who desires to compromise the integrity of Fedora through association with a third party proprietary solution for hosting of fedora software/other repositories, myself included. For what it is worth, I agree it is better to try to work through the problems and at the very least try to understand them. In this case Pagure, or not depending on the direction decided, maybe does come as a test of Open Source virtue and should be the impetus to drive more community involvement to address the need.

Point of fact in regarding my issues I ran into with Pagure, I wasn’t looking for a comfort zone, i was trying to solve a problem which at the time I was certain I was the creator of.

I agree 100% with that statement. I am quite comfortable using Fedora, and getting comfortable with Silverblue.

The single most common question I get asked by people I know or have encountered, who are struggling over the decision to try the (Fedora) OS is about the initial learning curve and the leap (for them) out of their comfort zone (which is commonly Windows). This also seems to be one of their compelling reasons for using Fedora as a desktop. The newness, and freedom of choice, it can be overwhelming for some.

Indeed, there are. But which one to choose, or just stay and address the shortcomings with Pagure? Two questions with an if conditional, certainly something a handful of programmers can resolve over coffee.


#38

Well, it sounds like you should get someone bragging about it and exposing the interesting tasks to the community to get engagement.


#39

+1 here. One of the “selling points” for me as a user of Fedora was that I was getting a RedHat Linux workstation without having to update my RedHat Linux version I bought.
The workstation is the face of Fedora to most users I would bet.

I don’t think CI/CD/version control/issue tracking/mini-Kanban source development is one of them unless Fedora can earn revenue because “the Fedora way” has a compelling advantage over GitHub’s to paying customers. If IBM / Red Hat want to offer Pagure to customers, let them say so. Otherwise, let’s move to GitHub, or have a bake-off between GitHub-, Altassian- and GitLab-hosted repositories.

As for my part in this Pagure/Github/GitLab debate, I merely asked in the beginning for some assistance with an issue I was having with Pagure commits. I was the creator of my issue, and so wanted to resolve it. In the end, I was more the problem than Pagure (which was my initial POV on it anyway), and am in the process of getting to the “happy state” with my fork of the Silverblue docs repo. It does seem to me that this discussion has been going on within Fedora, aside from the issues I encountered when trying to contribute to Silverblue doc’s, around the suitability of Pagure for the task it does. That is not a bad thing though, since if my little problem was able to balloon this into a discussion of this magnitude, there must be underlying issues that need addressing around the use of Pagure.


#40

I don’t see why there is no ‘move to gitlab’ poll option. I’d be fine with moving from pagure to gitlab, if the current state of pagure is sufficiently problematic for the project and the problems aren’t likely to be resolved sufficiently in the short term (although it’d be nice to see some contributions to pagure instead - it’s not a hard codebase to work on, when I run into something in it that annoys me, I usually try and fix it). Moving to github seems less desirable.