On Mon, Mar 30, 2020 at 8:08 AM Julen Landa Alustiza < jla...@fedoraproject.org> wrote:
> > > 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. We published the full requirements gathered from all stakeholders alongside the blog > 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 felt that the discussions came to a natural conclusion for each stakeholder group. I should have returned to that thread and updated folks that we had taken all the requirements in, that's on me, you have my apologies. > > 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. > I can't speak to how the community blog structures it's priority queue but I opened the mailing thread this morning due to the weekend. > > 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 > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig>
_______________________________________________ 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
