I understand what youâre saying. As a place for checking out what the community thinks, the Fedora forums are better than Twitter and there is no other fairer way of taking big votes where many people can express their opinion - for this forum, you need a Fedora account, so it makes the most sense. We cannot make it mandatory via technology that only those people vote, who are using Silverblue. Had we wanted to not listen, we could have just moved or done a Twitter poll, as we consider those more as a snapshot of what the people on Twitter who are somehow related to the account think. We have such a poll running currently, about rolling releases. Many people have asked but it is unlikely that we will have rolling releases. It is still important to check out how many people actually want them, so we can eventually ask for it or change things when the timing is right.
Ad #1: We did ask the Silverblue team. The wide majority of the core contributors wanted GitHub (see reasoning explained above and in the previous polls), so the next step was to gauge whether the community would be ok with that. It took several discussions after the 50/50 vote to see what weâre going to do next. The decision made now is simply by âwe have a split community, so whatever we do, itâs not great, but at least we can work better and have better visibilityâ. Some decision have to be made. What makes it right to choose Gitlab if itâs a 50/50 vote? What makes it a fake community circus to go with GitHub if itâs a 50/50 vote? Would you be posting the same things if it had been 49/51 Gitlab/GitHub? We didnât choose a 50/50 outcome. Weâd have preferred a clearer outcome either way in order to avoid discussions like this.
Ad #2: The specific issue was not resolved. If @jakfrost would like to chime in, feel free to do so. Otherwise, Iâll explain: Merge conflicts happen and not everyone needs to know all git commands in order to contribute to Silverblue. Knowing git should not be mandatory and weâre happy about contributions to the documentation and everything else. Neither should it be required to have to be on your laptop to resolve merge conflicts - both GitHub and Gitlab offer merge conflict resolution via UI which means it is fast and simple for everyone involved. So, no, the original issue was not resolved, and neither are the other bugs and lack of features (forwarded as a document to someone from the Pagure team, some of the things already exist as issues) in Pagure. Most importantly, there is a lack of resources to fix all the issues. Iâd like to not derail this thread into another Pagure discussion, but no, the specific issue was not resolved after all.
Ad #3: The first post is maybe confusing about the Gitlab instance versus hosted - we did say previously that a hosted Gitlab only makes sense if there is an on-premise Gitlab in sight which there isnât. Using hosted Gitlab we have less visibility and no cross-referencing but we have the option to easily migrate to a Fedora Gitlab if that was to happen (for which there are no plans as of today). Regardless, if the community had wanted Gitlab, weâd have gone with Gitlab, as we hope there will be more contributions which would help us improve the project faster. It does increase overhead for us, but it works.
What exactly is it that youâd like differently? We should have just moved to GitHub because itâs what the majority of us wanted from the start but couldnât do? We should have stayed still on Pagure because the outcome was 50/50? This is about documentation and issues only, nothing else changes. These two things are the easiest ways for newcomer contributors and should be on a known platform. Gitlab is one of the two main known platforms for this. Personally, I very much like Gitlab. From a professional and project perspective, GitHub is the right choice. From a community perspective, GitHub is 50/50. I already asked you, how much time are you willing to invest in the projectâs documentation? Iâll gladly work with you to get things into the documentation and have your name on the authorâs list even if you never want to click on a GitHub link.