20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen: > > On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote: >> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amolo...@redhat.com> wrote: >>> >>> ### Other Updates >>> >>> #### GitForge Decision >>> * After evaluating over 300 user stories from multiple stakeholders we >>> have aligned on a decision for the Gitforge that CPE will operate for >>> the coming years. We are opting for Gitlab for our dist git and >>> project hosting and will continue to run pagure.io with community >>> assistance. >>> * Check out our GitForge decision on the Fedora Community blog >>> https://communityblog.fedoraproject.org/ >>> * And at the CentOS blog page >>> https://blog.centos.org/2020/03/git-forge-decision/ >>> * Keep an eye out for mails in the coming months to the devel lists as >>> we plan transitions and next steps with GitLab >>> * We would like to express our sincere thank you to all who >>> contributed requirements to us! >>> >>> >> >> I'm going to start with the delivery of this decision sucked. If I >> hadn't been alerted to look for this by other folks due to my advocacy >> and community building work around Pagure, I would *not* have known >> that the decision had been made. This is in contrast to the *big deal* >> that was made about starting this "decision process". I don't know if > > Indeed, it seems like the lead got buried. I, too, had missed the > announcement. I guess I'll make more effort to read these weekly status > updates.
From the original blow post: https://communityblog.fedoraproject.org/git-forge-requirements/ > How will information be gathered and disseminated? > > It is recommended that both Fedora Council and CentOS Board gather input and present their concerns in a manner that is consistent with how their communities work. The RHEL and CPE requirements will be gathered through Red Hat communication mechanisms and presented publicly via a HackMD file to ensure transparency in their source. This will be published and distributed in due course. Additionally, a live video call and associated IRC meetings will be held and advertised in advance to discuss the requirements, talk about concerns and address any questions. > We want transparency to be at the heart of this decision. Good promise, where are all those? No discussion, no advances, no proper information dissemination, nothing :( This announcement is not even on the first position on communityblog. I was expecting at least the same announcement visibility level for the final announcement that we had for the initial one: first position on communityblog blog + exclusive threads on the mailing lists. Well, actually I was waiting for those live discussions > >> there were folks counting on nobody noticing this or not, but this is >> not a good way to deliver effectively a major decision like this. I >> also absolutely *refuse* to deal with the fact that this thread was >> split into three mailing lists. All three are connected to this >> thread, and I will take responses from all of them and follow them >> accordingly. >> >> Enough about that, let's talk about the actual decision. > > Thanks for your comprehensive response here and for all the work you've done > to drive Pagure forward. > > V/r, > James Cassell > > >> >> So, you're going with GitLab. It's interesting to note that the >> particulars about going to GitLab are not even figured out. It is >> curious that "SAAS" is mentioned very prominently. That made me a bit >> more curious, so I looked at the "final" feature requirements. >> Needless to say, I was extremely disappointed. >> >> To put it bluntly, there are *zero* free and open source solutions >> that satisfy your needs. From this, I understood why you said GitLab >> and SaaS. You want GitLab Ultimate, the proprietary solution that >> includes several extra features on top to satisfy the following >> requirements (quoted from your blog post): >> >>> * There is a need for CentOS Stream to integrate with a kernel workflow >>> that is an automated bot driven merging solution (merge trains). This >>> allows for richer CI capabilities and minimizes the need for human >>> interaction >>> * Gitlab allows for project planning capability which could make multiple >>> trackers such as Taiga redundant, allowing for the planning and tracking to >>> reside within the repo. It would enrich the current ticket based solution >>> that Pagure has evolved into for some groups >> >> These two requirements *alone* automatically force us to GitLab >> Enterprise Ultimate Edition, as there is no other solution available >> that satisfies those requirements in one product. Merge trains *is* a >> feature of Pagure when combined with Zuul, but GitLab's project >> planning features do not exist in *any* FOSS product, including GitLab >> CE (or GitLab Core as they call it now). >> >> There are mentions of other work that CPE team wants to do to better >> improve Fedora. Okay, sure. I even agree with some of them. And the >> time bomb that is FAS is definitely worth the attention (note that I >> am somewhat involved in the development of the Fedora AAA solution and >> am also working on trying to develop a community around it so it >> doesn't implode like virtually every other project under the Fedora >> umbrella, more on *that* a bit later). >> >> However, nobody has given me or anyone else in the Pagure community >> (which yes, is more than Pierre-Yves, thank you very much!) any >> concrete details of deficiencies they'd see that is not satisfiable by >> the community within a year before now. I've spent a little over a day >> analyzing the user stories and thinking about the gaps between Pagure >> and what the community wants, and I want to give some perspective here >> for some of these. I'm happy to accept refutations and other details >> to further enhance the color of these stories, of course. >> >>> 5 >>> As a RH Developer >>> I need the ability to privately comment on a PR >>> so that confidential information does not leak outside Red Hat >> >> Ignoring the mountainous levels of terrible problems that such a >> feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I >> were literally discussing this with a Mageian who was interested in >> this feature for Pagure weeks ago. We had identified the feature as >> not difficult to implement but also simultaneously nobody really >> *wanted it now*. It surprises me that this is something that should be >> considered an important feature to preserve. It's actually a very >> *rare* feature, and does not exist in any forge today, presumably >> because it's actually a horrifically bad idea and antithetical to open >> development. GitLab itself lacks this feature, in all variants. >> >>> 16 >>> As a general user >>> I want to be able to create a bot/service account >>> That integrates with the gitforge in the same way as a human does >> >> This is a nice ask, but it's not a reasonably easy one to implement >> with our current system. This is a problem I've struggled with at >> $DAYJOB with GitLab as well, and frankly, if you have account >> integration with a single-sign-on system (which virtually all >> large-scale Git forge instances do), you can't really easily have this >> without causing major problems. Not the least of which is how you >> resolve account namespace collisions. There are also problems with >> maintaining and auditing, too. But it's certainly something I'd like >> to see in any forge (note that none implement this today either). >> >>> 29 >>> As a General User >>> I want to access repos fully over https >>> For environments where SSH is blocked >> >> I would be really curious if the Red Hat Infrastructure Security guys >> have changed their opinion on this after four years of blocking the >> development of this feature in Pagure. The two major reasons we don't >> have this in Pagure are: >> >> * There is a very strong push to not provide a way to bypass the SSO >> (ignoring the fact that SSH keys are effectively a bypass, but most >> security people are two-faced about this anyway) >> * There is a very strong push to not provide LDAP integration so that >> the required HTTP(S) Git proxy server would not be able to be >> implemented. >> >> Note that for GitLab, unless you configure it to have access to LDAP >> or set up personal access tokens, you cannot use HTTP(S) push at all. >> Once again, this totally bypasses SSO. If the same rules that applied >> to Pagure apply to GitLab, nobody is getting this feature anytime soon >> with GitLab. If the attitude toward this feature has finally changed, >> I'd love to know. >> >> Also, for those who don't know, Fedora's Dist-Git supports HTTPS push, >> and has for almost a year: >> https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits >> >> This is done by *forcing* an SSO flow for *fedpkg* itself and >> leveraging it as a credential and auth point. Unfortunately, this is >> not a general purpose feature because there's not an easy way to do >> that, so it's unavailable on pagure.io at this time. This mechanism >> for HTTP push is *not* possible with GitLab, and would be quite >> difficult to implement due to the crazy architecture internally. But >> if more *normal* HTTPS is acceptable (like through auth tokens or LDAP >> auth), then this is something that could be relatively quickly added >> to Pagure (there was some old code that never got merged two years >> ago, I still have it archived somewhere...). >> >>> 31 >>> As a General User >>> I can request access rights to a repository >>> So that I can contribute in a low friction manner >> >> I honestly don't know entirely what this means. Are we talking about >> having partial commit access (commit access to only some branches)? If >> so, there's a PR out for implementing this in Pagure under review: >> https://pagure.io/pagure/pull-request/4786 >> >> >>> 34 >>> As a General User >>> I want a mobile native app >>> To allow me contribute while away from my desk >> >> I don't have words for this... You folks know that only GitHub.com has >> an official mobile app, right? And the experience is not great... >> 🤦♂️ >> >>> 42 >>> As a General User >>> want a GUI to interface with the system as well as a CLI >>> so new users have an easier way to interface with it >> >> I'd like to point out that most popular GUIs for Git stuff are not >> forge specific and do not even do much for forge integration. But >> sure...? >> >>> 44 >>> As a General User >>> I want a temporary file (gist) >>> So that I can share code easily >> >> There seems to be a misunderstanding here... Gists are not temporary. >> They're lightweight *permanent* Git repos (in GitHub). GitLab stores >> them (called Snippets) as permanent things in the database (not a Git >> repo). Are you trying to conflate pastebin use-cases here? That's >> probably a very bad idea... >> >>> 46 >>> As a General User >>> I want to be notified of CVEs in my code >>> so that I can stay on top of critical vulnerabilities >> >> There are *zero* FOSS solutions for this in the forge space. This >> feature does *not* exist below GitLab Ultimate (the former Gemnasium >> service was integrated into it). >> >>> 47 >>> As a General User >>> I want integrated keyword support >>> to allow me automate a lot of my actions such as a rebuild / retest >> >> This is not a forge feature, this is a CI service feature. And note, >> GitLab CI does not support this. >> >>> 49 >>> As a General User >>> I want to gain analytics and insights from my code >>> so that I can have historic context to make decisions moving forward >> >> GitLab Enterprise features... >> >>> 51 >>> As a General User >>> I would like to track my work in an Agile manner >>> allowing me centralise all my planning in my forge and gain insights into >>> how I am working. >> >> GitLab Enterprise features, as mentioned earlier. >> >>> 56 >>> As a General User >>> I want registry integration >>> so that I can store dependencies >> >> No, you don't. You *really* don't want this. Are you *sure* you know >> what you're asking for? You're suggesting three things here: >> >> * OSS solutions for this (including Fedora's own package/container >> infrastructure and hosted quay.io) are not good enough >> * You are ready to have even more arbitrary data stored in the Git >> system that may not follow our legal compliance >> * You are willing to pay the cost of having even more data stored >> >>> 57 >>> As a General User >>> I want the ability to have a private branch >>> So that I do not need to leave the code tree I am already in >> >> Just so everyone is *crystal clear*: you literally cannot do this. Git >> does not have a concept of private branches or private refs within a >> repository. You can have private forks, of course. And Pagure supports >> those just fine, just like GitLab and GitHub do. >> >> (also note, we *intentionally* do not have private repos turned on... >> if we want this, we could just flip a switch...) >> >>> 62 >>> As a General User >>> I want automerges when specific acceptance criteria are met >>> So that I do not need manual intervention >> >> So... Mergify then? This is not *currently* a GitLab feature, and >> Mergify does not support GitLab, last I checked. Only GitHub.com. It's >> been on my bucket for a while to look at extending Mergify to support >> Pagure for this, as it's a really nice feature... >> >> I want to take a moment to reflect on something that has been on my >> mind for a while now: Fedora has not done a good job being an umbrella >> organization. As an organization, we have done a huge disservice to >> all Fedora-affiliated projects by not allocating any community >> development effort or marketing effort. I know that Matthew Miller >> feels Fedora should evolve to being an operating systems factory[1] >> and to some extent that isn't a bad thought. But the Fedora Project >> was always intended to be more than just the Fedora Linux >> distribution. It has always been intended to be a home for Free and >> Open Source innovation. In a Hacker News thread last year[2], I had >> reflected on how proud I have been to be part of Fedora because we, as >> a community, weren't willing to just give up like so many others do. >> When FOSS solutions were inadequate, we built better ones. We've >> invented things that didn't exist before, and jump-started >> conversations about concepts that people didn't think of before. But >> there has been a bit of a dark side to this for Fedora. We've rarely >> given our projects an opportunity to grow beyond us. Off the top of my >> head, the *only* project that technically *started* in Fedora and >> became successful was Ansible. And if I'm being totally brutally >> honest, it was only successful because the engineers who were >> passionate about it had to quit Red Hat and create AnsibleWorks to >> push it to success. It was successful *despite* Fedora. Maybe soon >> we'll be able to add HyperKitty and Postorius to that, as I've been >> seeing deployments of that come online over the past few months. It's >> taken a while, but HyperKitty is finally taking off. There was one >> person I talked to who told me that HyperKitty made mailing lists >> enjoyable and she didn't know the project came from Fedora originally. >> Again, seeing success despite Fedora. >> >> When I talk to folks in other communities and show them some of the >> infrastructure projects we've developed as part of trying to build >> communities around them, I've literally had people tell me that they >> wish they had known we made them before, because it solved all their >> problems they were struggling with. That's both amazingly uplifting >> and terribly depressing at the same time. I'm not even putting in a >> lot of effort and we get so much more out of it. It didn't take a lot >> for me to get openSUSE interested in our new AAA solution and >> contributing. That tells me that we're just not trying. And really, >> that's obvious. Even a simple comparison of the Fedora and openSUSE >> project landing pages show that Fedora gives zero attention to the >> projects that exist under its umbrella. When you look at the openSUSE >> landing page, the distribution and major software projects under the >> umbrella are all broadcasted there. It makes it so much easier to >> discover and generate interest. I'm not saying I love every aspect of >> the openSUSE marketing. Far from it! But this is one thing they do >> right that we do terribly wrong. And then we sit back and wonder why >> our projects fail to generate interest beyond a few folks in Fedora >> itself. It's a self-fulfilling prophecy. This is something we need to >> fix for *all* our projects: present and future. >> >> In the end, I think the biggest disappointment of this process is that >> it feels like it demonstrates that Fedora leadership and management is >> not as committed to its mission and vision[3] as I hoped it was. I >> realize that I should not be surprised by this. Most of the leadership >> and management are no longer the idealistic people they were when they >> first became involved. And it's even harder to be idealistic when it's >> so easy to give in when you work for "open source company" that >> increasingly uses proprietary software to manage its workflow (to be >> fair, I think at this point virtually all major companies do this, >> which more or less demonstrates the amoral nature of these entities). >> Maybe I'm just an old remnant of a bygone era, but I personally remain >> somewhat idealistic, even as I have progressed over the years. I also >> remain hopeful that other members of the community are of similar >> mind. And perhaps this is a bit of a fool's hope, but I hope the CPE >> team reconsiders their decision, or at least would be willing to >> provide more context on the gaps they felt pushed them over so they >> could be prioritized for Pagure development (and maybe we can develop >> them fast enough so that we don't have to switch...). >> >> I think this is also an important indicator that Open Source has *not* >> won and it is *not* the default. People who keep saying otherwise need >> to seriously look hard at the landscape and realize that we have a >> long way to go before Open Source becomes the true default. It >> behooves us to become cognizant of this and push for freedom whenever >> and wherever we can. >> >> As for me? Well, I will do my best to try to help develop the Pagure >> community. I'm still committed to assisting the Free Software >> Foundation and other communities with using and contributing to >> Pagure. I hope others within the community will consider helping too. >> Pagure provides unique features that do not exist in any other forge, >> in large part because it is driven by an ideal that open data and >> freedom should be core tenants of software project management. And >> hey, I hear whispers of new Pagure instances being set up all the >> time! We're doing something right here, and it'd be a shame to >> squander it. >> >> Heh, the irony is that I started using and contributing to Pagure >> *because* I was burned by GitLab... >> >> >> [1]: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZBU4MYRMMAE2Z7DL4NPPECTMX2FBQAVL/ >> [2]: https://news.ycombinator.com/item?id=19356307 >> [3]: https://docs.fedoraproject.org/en-US/project/ >> > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Julen Landa Alustiza <jla...@fedoraproject.org> _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
