We’d like you to participate in an important community decision for Fedora CoreOS. Please read the introduction in the following form and vote for where you would like to see feature discussions, bug reports, and similar topics happening.
As a soft measure to prevent multiple votes, you’ll have to sign in with a Google account. In case you do not have or want to use that, please contact us in #fedora-coreos on IRC and we’ll provide you with an email you can use to cast your vote.
Please share the form link so we can have as many votes as possible by July 4th 23:59 EST.
Having read about the topic, I think we should use Pagure and mirror repos to external repositories. That said, I think we should consider GitLab instead of GitHub.
Migration is not an issue since GitLab provides a very nifty “GitHub Import” tool.
In a preliminary vote among the current Atomic and CoreOS developers we had a very clear vote for GitHub where the vote options were GitHub, Gitlab, Pagure, and “other”. GitHub won that vote, but we have some very dedicated Pagure users with valid arguments, so we decided this is a good thing for the community to vote on as we’d like more people to contribute.
We did not want to put up many choices as we want to see whether there is a clear decision - but the comments are open and there is the “other” option to put Gitlab.
Let’s wait until next week so everyone has had a full week to cast their vote, but so far I can tell that the community vote mirrors the developers’ vote where Gitlab was an actual option and stayed way below 10%.
I find that also rather sad as I have voted for Gitlab as well - it is in my personal view the best option of the 3 but there are significant disadvantages from a community perspective, for example why not use existing Fedora infrastructure, why not use the existing GitHub tools where everyone already is on board, and then there is also the decision of hosted Gitlab or on premise which needs dedicated infrastructure people (who’d have to come from Fedora and then it makes even less sense to not use Pagure).
As a quick result just to inform everyone, we’ve had 112 votes for GitHub out of 184 votes altogether (182 were done via form and 2 externally from people who do not use Google accounts).
We’ll be working on publishing the results in a proper form with commentary and addressing several points that were raised by community members in the comments.
This is a very delicate question. In my view, to make more sense, the project should be in Pagure (because it’s a Fedora Project Infrastructure). However, if there is an intention to make more visible to new collaborators, it’s necessary that the project be where the masses are. I think those who voted for Github think this way. What worries me a little, is that this kind of thinking ends up killing the pagure.
This is the point, my friend. I agree with you!
And maybe the mirror option really solves this. Even the international community “knows little” about the Pagure. Maybe it’s the opportunity to get to know him better.
There’s no real reason why contributions couldn’t be accepted from the GitHub mirror, either.
Pagure supports remote pull requests, and it would be easy to just make a service that would automatically create the required remote pull request from a GitHub fork remote to the main Pagure repo.
Then of course, after declaring it to be merged, Pagure would merge it, then push to GitHub, and close the GitHub PR accordingly.
In my opinion, the canonical repositories should be under a fedora-coreos organization on Pagure that’s wired to a corresponding organization on GitHub with the appropriate integrations.
Please check out the front page @ https://coreos.fedoraproject.org/ - I’ve just uploaded the results and they will stay on the front page for a few months until they are moved to the FAQ or other pages that might be added to the website once the first Fedora CoreOS release approaches.
The plan was to share them in a more formal form with commentary (the team is very busy with the technical work), but in order for the community to have a feeling of the votes and general results, the main page now features the results in a little bit more detail. Let’s recap them here as well (replicating the information on the website), so more community members can share their comments - this also makes it easier for team members to provide commentary.
Textual information
The overall vote count of 184 (182 on the form plus 2 external votes that had no Google account) is distributed as follows:
112 GitHub
57 (55+2) for Pagure
14 Gitlab (mix of on premise and hosted variant votes)
1 “just keep Gentoo CoreOS”
That makes over 60% for GitHub with some comments on Twitter and the form saying that they voted for GitHub because Gitlab was not an option in the poll. There were 40 comments in the form which were helpful in getting a feeling for the actual and potential community. The main takeaway from the comments was that people feel either upset about GitHub or about Pagure. As it is not possible to please everyone, we are going with the clear result on the vote and using GitHub for those discussions that are not a good fit for IRC or the forums.
Many thanks to all of you who participated and gave us feedback - please continue to contribute with ideas, code, questions, and conversation.
GitHub is best for discovery - nobody searches GitLab or Bitbucket for projects. I use them for private repos, but if I want to engage a wider community than my workstation or laptop, I’m going to put my repo on GitHub.
I use GitLab because I like to support open source. GitHub is not open source.
Also, the CI capabilities of GitLab are incredible. Nothing similar exists on GitHub, which forces you to use extra software for CI, like Jenkins. I also like the CI syntax from GitLab more than the one from Jenkins. Considering the issue you highlighted, regarding the popularity of each tool, I don’t think it would be an issue if some automated feature would update the code to all of the mentioned servers, so that people can be SURE it can be found anywhere. However I would still keep the main on GitLab.
But obviously I am biased here since I am a GitLab fan.
