Dne út 31. bře 2020 21:00 uživatel Clement Verna <cve...@fedoraproject.org> napsal:
> > > On Tue, 31 Mar 2020 at 14:57, Neal Gompa <ngomp...@gmail.com> wrote: > >> On Tue, Mar 31, 2020 at 7:10 AM Clement Verna <cve...@fedoraproject.org> >> wrote: >> > >> > I just want to give a bit of insight from someone who is working day to >> day on Fedora's infrastructure, since I believe that might help give a bit >> more empathy towards the Why of this decision. >> > >> > For me the Fedora's Infrastructure is in a very bad shape there is a >> fair load of technical debt and trying to change or improve anything >> results in a long list of reason why we can do it because services X >> depends on service Y which depends on Z. Since I joined the CPE team >> (little bit more than 2 years ago) we have not been able to make any kind >> of significant progress towards fighting this technical debt. Every year we >> fill a white board with what needs to be done : >> > >> > Python 3 apps migration, >> > FAS replacement, >> > fedmsg retirement, >> > FMN replacement, >> > Fedora-packages replacement, >> > PDC replacement, >> > Porting application to OIDC, >> > Improve Releng automation, >> > Improving Anitya and the-new-hotness, >> > ..... >> > >> > Every single year the same items are coming back because we spend most >> of our time firefighting services to keep users happy and keep Fedora >> release schedule. This has a very demoralizing effect on the people working >> in the team, it seems like we will never be able to make any significant >> improvement, and our day to day job is to close couple tickets and you keep >> watching the pile of tickets growing. There is no feeling of accomplishment >> and a general sentiment that whatever we do, it will suck. >> > >> > A little over a year ago we have expressed our need to drop >> applications, this is something we have to do to be able to stay sane and >> keep a sustainable life-work balance. From that effort to handover >> applications (Elections, Nuancier, Fedocal, Badges) to another group of >> people in the community, not much happened mainly because of GDPR and the >> legal responsibility of owning such applications, but as far as I know we >> don't do much maintenance work on these applications any more since we now >> have a few volunteers that are looking after them or helping with finding >> an alternative solution. >> > >> > Now on the list of application we develop and run, I think Pagure is >> logical candidate to try and find an alternative to it, but before doing >> this it was important to make sure we captured all the use case and feature >> needed from a git forge and see if any of these justified spending cycles >> in development and maintenance work. My understanding of the decision is >> that Pagure does not provide any significant advantage over GitLab. I know >> that for many, the fact that Pagure is developed by Fedora is an advantage, >> but from my perspective as someone that as to deal with all the other >> services in Fedora's Infra this is a major disadvantage. >> > >> > Overall I think it is important to keep in mind that there is a lot of >> work happening behind the scene to provide the people in the Fedora >> community a good experience contributing to Fedora. I think we are doing a >> good job at it, but that takes us an enormous effort and over the long term >> this is not sustainable, also keeping in mind that we keep adding and want >> to keep adding new things to Fedora. >> > >> > I hope that my perspective helps a little. >> > >> >> Clement, >> >> I want to say thank you for all the hard work you do as a member of >> the Fedora community and as a member of the CPE team. You've done >> fantastic work for the community and it's always a pleasure to work >> with you. And that goes for all the members of the CPE team. I totally >> understand where you are coming from. And it *is* very demoralizing to >> see the same things over and over again, looking as if you've made no >> progress on these things. I've been there with my work at $DAYJOB >> before, many times. And as you and others are aware, I've been poking >> around throughout infrastructure projects to help with some of these >> initiatives over the years, so I'm keenly aware of the size and scope >> of many of these. >> >> However, I think some of this is self-inflicted. I don't want to >> entirely rehash my original email with my thoughts on this, so please >> read that for more detail[1], but I think we *really* should consider >> that the lack of community exposure to to the codebases themselves >> (especially as an avenue for contributing to the Fedora Project!) is >> an underlying problem here. This has created a persistent cycle of >> "community member makes cool project to support Fedora" → "it gets >> adopted silently and no one really talks about it or advertises it" → >> "nobody knows about it and the community member is the only one >> working on it" → "the community member burns out and it gets piled >> onto Fedora Engineering/CPE to maintain". This is basically how CPE >> team got >100 codebases. >> > > I agree with that, but for me there also a bit of a chicken and egg > problem. I think we don't make more promotion and help people to onboard > with the code base because we already don't have the time to maintain > properly all these services, half of them if not more (I might be > exaggerating a little :-) ) don't have an up to date Readme file with > instruction on how to setup the development environment. > Another aspect that does not help a lot of our code bases are legacy > application using technology stack from more than 10 years ago, try to find > anyone interested to learn about Turbogears2 and mako templates (tech stack > for fedora-packages). > > >> >> This is a cycle that I've been *trying* to break. I'll be the first to >> admit that I'm not the greatest programmer in the world, but I try to >> contribute in terms of code, code reviews, testing, etc. But one thing >> I've been doing for the past couple of years is *community project >> advocacy*. I've been examining all the projects we have in Fedora and >> seeing which ones I can help seed communities out of. My hope is that >> by nurturing communities that are all interested in the success of >> these projects, we can make them more independently sustainable. >> > > Thank you for all your work and efforts, this is really appreciated. > > >> >> As for Pagure itself, I think this is where we fundamentally disagree. >> I think it behooves us to own and provide an experience tailored for >> our community from beginning to end. That's why we have Koji, Bodhi, >> Dist-Git, and many other tools in that part of the lifecycle. The >> packager experience is literally the lifeblood of the project, and our >> contributors are the core of what makes Fedora successful. Pagure >> gives us an opportunity to do right by them that I *really* don't >> think we can do with any alternatives. >> > > I am not convinced that having a custom git forge is mandatory to provide > an great experience to the community. I wasn't really around the community > before Pagure, but I as far as I understand it the experience was better > before Pagure and people were able to do more self servicing. I believe > that there is an alternative to having the packager workflow tightly > coupled to the git forge, this is also maybe a good opportunity to rethink > some of that workflow and explore different solutions. > > >> >> That does *not* mean that CPE team should be the sole owner of the >> Pagure *codebase*. On that point, I agree. And that's why I've spent a >> lot of time and energy since late 2018 working on building up that >> community. It's finally starting to bear fruit too: there's at least >> one entity interested in building a product around it and contributing >> to help support that product, there's the FSF preparing to launch a >> new forge using Pagure, there's the Trisquel GNU+Linux distribution >> working on a Pagure deployment to host their code and packaging, and >> there's a few other things I've got up my sleeve to help broaden the >> community with not just users, but also contributors. >> >> Are there deficiencies in Pagure? Of course there are. I'm not >> claiming that Pagure is perfect. But I think that keeping on with >> Pagure and giving that community an opportunity to close the gap on >> needed features for Fedora/CentOS/Red Hat is the right way to go. >> Right now, I don't *know* what the important gaps are. I can make some >> guesses, but it'd be a lot better if we had a list of missing features >> and their relative important and why. That would help focus >> development to meet those needs. >> >> The Fedora community itself has indicated that they want to keep on >> with Pagure, and many Fedorans are Pythonistas, which means that >> everyone can easily contribute to help make it better for everyone. >> > > Genuine question, from the people that have participated in this thread, > How many could dedicated couple hours a week to work on Pagure ? I think > many community member are already struggling to keep up with their current > level of contribution, I am not sure than everyone can easily contribute to > Pagure. But I am happy to wrong :-). > I can look at the search-related issues that were mentioned here...as a starting point. But i am not going to be motivated by pagure being taken down from the dist-git's deployments. Also...using a proprietary solution for our git forge would be just totally lame. That should be out of question completely. clime > >> >> Anyway, I hope this helps clarify my position on the matter! >> > >> [1]: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y5XXXHJCSDMOHA7FEZ3DNZYPGCTZBVH6/ >> >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 >
_______________________________________________ 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
