Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:00 PM, Emmanuel Seyman wrote: My initial reaction is that the lists of applications in categories 1 and 2 are very short. My second reaction is that this page doesn't sell me that I should use Python in any business-critical software... These categories are not complete at all. We didn't go through every application we own and put it to specific category. We only got through part of our list. It will be long process till we get through whole list. In the first CPE blog [0] about changes in our team you can see that we are currently maintaining 112 services and we have only 19 people to do this. Is release-monitoring.org also maintained by the CPE? It's being broken for ages and I feel it's a shame it doesn't get more love. I'm the main maintainer/developer of release-monitoring.org and I recently deployed a new version to staging environment, but I'm currently busy working with others on Rawhide Gating. I will have talk about future of release-monitoring.org on Flock, you can meet me there and we could discuss about this or feel free to add any bug to release-monitoring.org tracker [1]. There is currently one issue, that is blocking reporting bugs in bugzilla, unfortunately this is issue on bugzilla [2] side. I'm also trying to write blog posts [3] regularly about my work. Emmanuel ___ 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 Michal [0] - https://communityblog.fedoraproject.org/state-of-the-community-platform-engineering-team/ [1] - https://github.com/release-monitoring/anitya/issues [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1679385 [3] - https://communityblog.fedoraproject.org/tag/release-monitoring-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
Compiling with AddressSanitizer
Hello, I have been using a library for awhile now and have been thinking of submitting it to Fedora. Part of what I have been doing with it was compiling it using -fsanitize=address and leak etc. I’m kinda wondering about how that is handled with Fedora packages. Are we able to / should we provide library package versions that are compiled against these kinds of sanitizers? Or if someone wants to do that they should recompile the RPM with those flags and use it locally? Sincerely, — Nathanael ___ 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
Schedule for Thursday's FPC Meeting (2019-07-18 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-07-18 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-07-18 09:00 PDT US/Pacific 2019-07-18 12:00 EDT --> US/Eastern <-- 2019-07-18 16:00 UTC UTC 2019-07-18 17:00 BST Europe/London 2019-07-18 18:00 CEST Europe/Berlin 2019-07-18 18:00 CEST Europe/Paris 2019-07-18 21:30 IST Asia/Calcutta New Day: Friday - 2019-07-19 00:00 HKT Asia/Hong_Kong 2019-07-19 00:00 +08 Asia/Singapore 2019-07-19 01:00 JST Asia/Tokyo 2019-07-19 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 = New business = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:40 AM, Timothée Floure wrote: > Hello, > > I do not think it would be good for apps.fp.o to simply disappear: although > outdated, it does a pretty good job improving human-discoverability of our > services. I understand that longtime or active contributors are not really > affected but I believe the index to be helpful for newcomers (as it was in my > case). > > From apps.fp.o's README [1]: >> Right now, the apps side of Fedora Infrastructure feels scattered and all >> over the place. It seems like I learn that a new thing exists every couple >> weeks and it seems like there's not a single easy place where you can stumble >> into everything. > > Can we perhaps move the index to the main docs on [2] and replace the current > apps.fp.o by a simpler, intemporal page, linking to the updated list? Having > the page out of the 'standard' documentation workflow doesn't help keeping it > up-to-date... > > I will gladly take care of the changes. Any thoughts? I personally think thats a fine idea... might be good in a infrastructure specific area? We also have 'infra-docs' that might be good to move into the main docs site sometime ( https://docs.pagure.org/infra-docs/ ) Thanks! kevin signature.asc Description: OpenPGP digital signature ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 2019-07-17 at 22:00 +0200, Emmanuel Seyman wrote: > My initial reaction is that the lists of applications in categories 1 and 2 > are very short. Category 1 is not a list. It says: "For completeness we are highlighting one example of a Category 1 application that we will always aim to maintain and keep on the air." - i.e. there are several *other* things in Category 1. It's not entirely clear from the post whether the 2, 3 and 4 lists are meant to be complete, but from knowledge and belief I think at least 2) is not: there are other things than the wiki that would fall into that category. (I sure hope openQA does, cos we can't easily run it in Openshift, for instance). > My second reaction is that this page doesn't sell me that > I should use Python in any business-critical software... I'm not quite seeing the logic there? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
* Peter Robinson [17/07/2019 14:07] : > > It would be useful to have the CPE mission linked to directly, it's > mentioned a number of times in the post but I don't see a direct way > to get to it. It's in the first link on that page: https://communityblog.fedoraproject.org/outcome-of-the-cpes-teams-face-to-face/ Emmanuel ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
My initial reaction is that the lists of applications in categories 1 and 2 are very short. My second reaction is that this page doesn't sell me that I should use Python in any business-critical software... Is release-monitoring.org also maintained by the CPE? It's being broken for ages and I feel it's a shame it doesn't get more love. Emmanuel ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > > > > Good Morning, > > > > We posted this [1] blog today and want to open a mailing thread to garner > > feedback, field questions and get some thoughts from the Community on > > the approach that we in Community Platform Engineering (CPE) are taking. > > > > [1] > > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > > > > Two things that concern me at this time: > > > Ipsilon — Ipsilon is our identity provider. It supports multiple > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …) > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…). > > While it was originally shipped as a tech preview in RHEL it no longer is > > and > > the team working on this application has also been refocused on other > > projects. > > We would like to move all our applications to use OpenID Connect or SAML 2.0 > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an > > IPA-based solution, which in turn allows us to replace ipsilon by a more > > maintained solution, likely Red Hat Single Sign On. The dependencies > > are making this a long term effort. We will need to announce to the > > community > > that this means we will shut down the public OpenID 2.0 endpoints, > > which means that any community services that use this protocol need > > to be moved to OpenID Connect as well. > > There are two issues to unpack here: > > 1. We use a weird custom backend and custom protocol extensions. > > This should definitely be replaced if it makes sense. It’s more urgent > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > developers died a while ago… > > Naturally, the replacement is equally in a poor state, but may have > some legs someday: https://github.com/fedora-infra/noggin > > 2. Ipsilon development was only considered important as part of being > tech preview in RHEL and now it’s not. > > There are some major problems here. First of all, Ipsilon development > has been gated by a single person. That person also seems to have > trouble making time to review pull requests. There has been interest > from the broader community about using and contributing to Ipsilon, > since unlike Keycloak, it is written in an accessible language > (Python). > > Getting Ipsilon to Python 3 would be enough for me to get started on > bootstrapping some of the other interested parties onto Ipsilon, and > hopefully give us a more sustainable community long-term. I guess my question to all this is... Why? What's the goal? If Keycloak does everything Ipsilon does and more, what's the point of keeping a dead project alive instead of contributing to the active, lively one? If there really, truly is interest from the broader community, why not do a friendly fork, get all the work you want in, and see what the original maintainer thinks? For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace Pagure, or a generic notification service exists somewhere to replace FMN, or whatever, why spend time on such things we could be spending developing the few unique tools we need to continue building the Fedora distribution? Stopping along the way to build an identity and access management platform isn't going to make the distribution better. - Jeremy ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 15:38, Adam Williamson wrote: > On Wed, 2019-07-17 at 13:32 -0400, Neal Gompa wrote: > > My frustration is that people who aren’t working at Red Hat have *no* > > avenue to help support the Project’s infrastructure. > > On what basis do you say this? The whole infra process is set up to be > a Fedora process, not an RH one. You don't use any RH credentials to do > any work on Fedora infra. You use Fedora ssh tokens and certificates. > The servers are Fedora servers, hosted in a Fedora data centre. There's > You were doing so well up until this point. The majority of the servers are owned by Red Hat and the majority of them are hosted in 2 data centres that are rented by Red Hat. Stephen 'equally picky when its over 38 C' Smoogen -- Stephen J Smoogen. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On 7/17/19 10:32 AM, Neal Gompa wrote: > > I don’t have a problem with you saying you can’t maintain everything > and focusing on stuff *to* maintain. But I have been trying for > *months* to try to help in various efforts as a member of the > community. There’s very little I can do because there’s just simply no > avenue for the community to be involved. I'm pretty shocked that you say that, but obviously there's some miscommunication going on, we should try and figure out how to fix it. > I took over maintenance of the pagure package in Fedora and EPEL > because pingou couldn’t keep up with it and everything else for this > reason. In the process of that, I’ve become a contributor and try to > help where I can. Thats great, thanks! > And I’ve had a standing offer open with abompard to co-maintain the > Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even > today. Yep. He has had no time to polish things up, get them working with python3.7 and submit them. If you're willing you could ask him for the python 3.4 based packages to try and bring up and get reviewed. I can't speak for him of course. > I’m happy to do the same for Ipsilon, and I’d even like to become a > contributor once I’ve had a chance to get up to speed with it, like I > did for Pagure. Great! > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. Thats... not the case. Or shouldn't be. I was in sysadmin-main (root on all hosts) before I worked for Red Hat. For years. Others also joined via the community and were later hired by Red Hat. ...snip... I think there's several possible disconnects/issues around this. Fedora Infrastructure has always been very 'self driven' for contributions. We have had to be, due to the amount of time folks have to help / mentor people. So we see this a lot: Them: Hey! I want to help out with infrastructure! us: awesome! we have added you to the apprentice group to login and look around, please join our meetings, read our getting started guide, hang out in our channels and ask questions or chime in when you see something you want to help with, and look at our tickets. Welcome. Them: The folks who have done well with this model just start working on things, sending patches, asking on irc if they can help with X specifically, etc. Thats not great for people who want to be assign tasks or have a mentor. Additionally, the model has been that new folks start out with things, do them well then do more things and as they go they get perms to do those things. Many people want to jump to the end. "I want to maintain koji, give me access". Finally, infrastructure isn't nearly as interesting as it used to be. Many of the folks that would have been interested in helping are now off looking at openshift and openstack and microservices and other more exciting things. Anyhow, if there are specific things you want to commit to helping with or doing, let us know and we can try and get you able to do those things. It's not a cabal. We would love to have the help. kevin signature.asc Description: OpenPGP digital signature ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 14:10, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen > wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > >> > > >> > >> There are two issues to unpack here: > >> > >> 1. We use a weird custom backend and custom protocol extensions. > >> > >> This should definitely be replaced if it makes sense. It’s more urgent > >> now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > >> 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > >> developers died a while ago… > >> > >> Naturally, the replacement is equally in a poor state, but may have > >> some legs someday: https://github.com/fedora-infra/noggin > >> > >> 2. Ipsilon development was only considered important as part of being > >> tech preview in RHEL and now it’s not. > >> > >> There are some major problems here. First of all, Ipsilon development > >> has been gated by a single person. That person also seems to have > >> trouble making time to review pull requests. There has been interest > >> from the broader community about using and contributing to Ipsilon, > >> since unlike Keycloak, it is written in an accessible language > >> (Python). > >> > >> Getting Ipsilon to Python 3 would be enough for me to get started on > >> bootstrapping some of the other interested parties onto Ipsilon, and > >> hopefully give us a more sustainable community long-term. > >> > >> A final note here, I’m generally disappointed in how inaccessible > >> infrastructure resources are to the broader community, and while a > >> community OpenShift will alleviate some of that, I’m concerned that > >> more sophisticated services would still require the crap workflow we > >> have now for community vs infra. I’ve had thoughts about how to make > >> that better on a broader basis, but that’s probably for another time… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying > we can't maintain everything we are crap, or if we don't try to improve > things by maintaining stuff poorly we are crap. Do you want to beat us in > the morning or evening or just both times so you can work out your > frustrations on how badly we do stuff? > > > > Again my comments were not helpful and not useful for this conversation. > > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. > > I will be the first to admit that the various programs Infrastructure has run to try and get community members have not worked well. The problem being that the apprentice program and others need a lot more day to day hands on training we don't have time to do while trying to keep the ship from burning to the waterline. That means that while we try to get people involved, it turns into a large amount of we aren't available when the apprentice/newperson is and they aren't when we are. That said, we are putting everyone including new Red Hat people through being an apprentice before they get to join a sysadmin group. Then they are added to various sysadmin-* groups that fit the work they are doing. > But what is the point of saying stuff like this when we don’t have a > way to be a part of it? You’ve basically handed down ultimatums to the > entirety of the Fedora Project, contingent on the mostly RHer Fedora > Council (who has access to information the rest of us can’t ever get, > since we’re not employed by Red Hat) approving it. > > What information do you want? We have put out a list of all the applications we have, we are trying to make sure that we make people put in a ticket for things versus pinging us personally so it can be measured, and we have tried to make our infrastructure open for people to see what is done in it. That said there is always more things which can be done. > > -- Stephen J Smoogen. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 2019-07-17 at 13:32 -0400, Neal Gompa wrote: > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. On what basis do you say this? The whole infra process is set up to be a Fedora process, not an RH one. You don't use any RH credentials to do any work on Fedora infra. You use Fedora ssh tokens and certificates. The servers are Fedora servers, hosted in a Fedora data centre. There's a whole system by which you can apply to be an infrastructure team member which is not tied to RH employment. Did you try going through this process? Did it not work? https://fedoraproject.org/wiki/Infrastructure/GettingStarted -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 20:10, Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > >> wrote: > >> > > >> > >> There are two issues to unpack here: > >> > >> 1. We use a weird custom backend and custom protocol extensions. > >> > >> This should definitely be replaced if it makes sense. It’s more urgent > >> now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > >> 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > >> developers died a while ago… > >> > >> Naturally, the replacement is equally in a poor state, but may have > >> some legs someday: https://github.com/fedora-infra/noggin > >> > >> 2. Ipsilon development was only considered important as part of being > >> tech preview in RHEL and now it’s not. > >> > >> There are some major problems here. First of all, Ipsilon development > >> has been gated by a single person. That person also seems to have > >> trouble making time to review pull requests. There has been interest > >> from the broader community about using and contributing to Ipsilon, > >> since unlike Keycloak, it is written in an accessible language > >> (Python). > >> > >> Getting Ipsilon to Python 3 would be enough for me to get started on > >> bootstrapping some of the other interested parties onto Ipsilon, and > >> hopefully give us a more sustainable community long-term. > >> > >> A final note here, I’m generally disappointed in how inaccessible > >> infrastructure resources are to the broader community, and while a > >> community OpenShift will alleviate some of that, I’m concerned that > >> more sophisticated services would still require the crap workflow we > >> have now for community vs infra. I’ve had thoughts about how to make > >> that better on a broader basis, but that’s probably for another time… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying we > > can't maintain everything we are crap, or if we don't try to improve things > > by maintaining stuff poorly we are crap. Do you want to beat us in the > > morning or evening or just both times so you can work out your frustrations > > on how badly we do stuff? > > > > I don’t have a problem with you saying you can’t maintain everything > and focusing on stuff *to* maintain. But I have been trying for > *months* to try to help in various efforts as a member of the > community. There’s very little I can do because there’s just simply no > avenue for the community to be involved. > > I took over maintenance of the pagure package in Fedora and EPEL > because pingou couldn’t keep up with it and everything else for this > reason. In the process of that, I’ve become a contributor and try to > help where I can. > > And I’ve had a standing offer open with abompard to co-maintain the > Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even > today. > > I’m happy to do the same for Ipsilon, and I’d even like to become a > contributor once I’ve had a chance to get up to speed with it, like I > did for Pagure. > > My frustration is that people who aren’t working at Red Hat have *no* > avenue to help support the Project’s infrastructure. Granted, this > isn’t exclusively a Fedora thing. CentOS has this problem, and > openSUSE is worse, since all of their maintenance scripts are > completely private behind a VPN that only SUSE employees have access > to. > > But what is the point of saying stuff like this when we don’t have a > way to be a part of it? You’ve basically handed down ultimatums to the > entirety of the Fedora Project, contingent on the mostly RHer Fedora > Council (who has access to information the rest of us can’t ever get, > since we’re not employed by Red Hat) approving it. > > I fully expect that the Council will approve this, because they’ve > been saying for months that Fedora Infra’s team can’t support it all. > But that’s the problem. It’s *not* a Fedora team. It’s *just* Red > Hatters who happen to work on Fedora. And their priorities are handled > based on all the things they work on, and that includes CentOS and > maybe even other things as part of Red Hat’s OSPO (though I’m not sure > of that just yet…). > > I’m not trying to beat you guys up, but I don’t know what you want > from us. Based on my personal experience, it’s hard for me to be > enthusiastic about helping anymore… I think what you describe Neal is the effect of the team being overloaded, there is simply not enough hours in the week (and some of us are working a crazy number of hours per week) for us to keep everything running and also be able to help with more community involvement at least this is my feeling. A lot of the discussion we had was based on the value the CPE team brings to Fedora. The reality is that we have limited resources and way *too* many projects (https://communityblog.fedoraproject.o
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 13:46, Brian (bex) Exelbierd wrote: > On Wed, Jul 17, 2019 at 6:44 PM Stephen John Smoogen > wrote: > > > > > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > >> > >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > >> > > >> > >> There are two issues to unpack here: > >> > >> 1. We use a weird custom backend and custom protocol extensions. > >> > >> This should definitely be replaced if it makes sense. It’s more urgent > >> now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > >> 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > >> developers died a while ago… > >> > >> Naturally, the replacement is equally in a poor state, but may have > >> some legs someday: https://github.com/fedora-infra/noggin > >> > >> 2. Ipsilon development was only considered important as part of being > >> tech preview in RHEL and now it’s not. > >> > >> There are some major problems here. First of all, Ipsilon development > >> has been gated by a single person. That person also seems to have > >> trouble making time to review pull requests. There has been interest > >> from the broader community about using and contributing to Ipsilon, > >> since unlike Keycloak, it is written in an accessible language > >> (Python). > >> > >> Getting Ipsilon to Python 3 would be enough for me to get started on > >> bootstrapping some of the other interested parties onto Ipsilon, and > >> hopefully give us a more sustainable community long-term. > >> > >> A final note here, I’m generally disappointed in how inaccessible > >> infrastructure resources are to the broader community, and while a > >> community OpenShift will alleviate some of that, I’m concerned that > >> more sophisticated services would still require the crap workflow we > >> have now for community vs infra. I’ve had thoughts about how to make > >> that better on a broader basis, but that’s probably for another time… > >> > >> > > > > I don't know what is worse.. that if we try to improve things by saying > we can't maintain everything we are crap, or if we don't try to improve > things by maintaining stuff poorly we are crap. Do you want to beat us in > the morning or evening or just both times so you can work out your > frustrations on how badly we do stuff? > > Stephen, I respect your read and interpretation of what is written by > Neal above. I also understand your lived experience. > > Thank you for your line, but you don't have to respect my comments as mine showed little respect to Neal or the list. I should not have sent it as is, I should not have flown off the handle, and I apologize for the comments. > I think what Neal is getting at is that we don't have any knowledge > yet about how the services we are looking for others (not infra team > members) to run will be managed. The current system is less than > desirable and what Neal is referencing. It'd be great to get more > detail about how we are enabling these apps to be run by others so we > can see what is possible. > > regards, > > bex > ___ > 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 > -- Stephen J Smoogen. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
Hello, I do not think it would be good for apps.fp.o to simply disappear: although outdated, it does a pretty good job improving human-discoverability of our services. I understand that longtime or active contributors are not really affected but I believe the index to be helpful for newcomers (as it was in my case). From apps.fp.o's README [1]: > Right now, the apps side of Fedora Infrastructure feels scattered and all > over the place. It seems like I learn that a new thing exists every couple > weeks and it seems like there's not a single easy place where you can stumble > into everything. Can we perhaps move the index to the main docs on [2] and replace the current apps.fp.o by a simpler, intemporal page, linking to the updated list? Having the page out of the 'standard' documentation workflow doesn't help keeping it up-to-date... I will gladly take care of the changes. Any thoughts? [1] https://github.com/fedora-infra/apps.fp.o [2] https://docs.fedoraproject.org/en-US/docs/ Cheers, -- Timothée signature.asc Description: PGP signature ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
> "FW" == Florian Weimer writes: FW> I strongly doubt this will be true indefinitely. I expect things FW> will change pretty quickly once partners can access and file bugs in FW> the other bug tracker. This is interesting in light of the fact that one reason given for not enabling Pagure issues for src.fedoraproject.org was because there was benefit in keeping bugs in bugzilla alongside the RHEL bugs. - J< ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 1:22 PM Stephen John Smoogen wrote: > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: >> >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon >> wrote: >> > >> >> There are two issues to unpack here: >> >> 1. We use a weird custom backend and custom protocol extensions. >> >> This should definitely be replaced if it makes sense. It’s more urgent >> now that RHEL 6 is going EOL next year, and FAS 2 is still a Python >> 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS >> developers died a while ago… >> >> Naturally, the replacement is equally in a poor state, but may have >> some legs someday: https://github.com/fedora-infra/noggin >> >> 2. Ipsilon development was only considered important as part of being >> tech preview in RHEL and now it’s not. >> >> There are some major problems here. First of all, Ipsilon development >> has been gated by a single person. That person also seems to have >> trouble making time to review pull requests. There has been interest >> from the broader community about using and contributing to Ipsilon, >> since unlike Keycloak, it is written in an accessible language >> (Python). >> >> Getting Ipsilon to Python 3 would be enough for me to get started on >> bootstrapping some of the other interested parties onto Ipsilon, and >> hopefully give us a more sustainable community long-term. >> >> A final note here, I’m generally disappointed in how inaccessible >> infrastructure resources are to the broader community, and while a >> community OpenShift will alleviate some of that, I’m concerned that >> more sophisticated services would still require the crap workflow we >> have now for community vs infra. I’ve had thoughts about how to make >> that better on a broader basis, but that’s probably for another time… >> >> > > I don't know what is worse.. that if we try to improve things by saying we > can't maintain everything we are crap, or if we don't try to improve things > by maintaining stuff poorly we are crap. Do you want to beat us in the > morning or evening or just both times so you can work out your frustrations > on how badly we do stuff? > I don’t have a problem with you saying you can’t maintain everything and focusing on stuff *to* maintain. But I have been trying for *months* to try to help in various efforts as a member of the community. There’s very little I can do because there’s just simply no avenue for the community to be involved. I took over maintenance of the pagure package in Fedora and EPEL because pingou couldn’t keep up with it and everything else for this reason. In the process of that, I’ve become a contributor and try to help where I can. And I’ve had a standing offer open with abompard to co-maintain the Mailman 3 stack as soon as it landed in Fedora. It’s still valid, even today. I’m happy to do the same for Ipsilon, and I’d even like to become a contributor once I’ve had a chance to get up to speed with it, like I did for Pagure. My frustration is that people who aren’t working at Red Hat have *no* avenue to help support the Project’s infrastructure. Granted, this isn’t exclusively a Fedora thing. CentOS has this problem, and openSUSE is worse, since all of their maintenance scripts are completely private behind a VPN that only SUSE employees have access to. But what is the point of saying stuff like this when we don’t have a way to be a part of it? You’ve basically handed down ultimatums to the entirety of the Fedora Project, contingent on the mostly RHer Fedora Council (who has access to information the rest of us can’t ever get, since we’re not employed by Red Hat) approving it. I fully expect that the Council will approve this, because they’ve been saying for months that Fedora Infra’s team can’t support it all. But that’s the problem. It’s *not* a Fedora team. It’s *just* Red Hatters who happen to work on Fedora. And their priorities are handled based on all the things they work on, and that includes CentOS and maybe even other things as part of Red Hat’s OSPO (though I’m not sure of that just yet…). I’m not trying to beat you guys up, but I don’t know what you want from us. Based on my personal experience, it’s hard for me to be enthusiastic about helping anymore… -- 真実はいつも一つ！/ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 6:44 PM Stephen John Smoogen wrote: > > > > On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: >> >> On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon >> wrote: >> > >> >> There are two issues to unpack here: >> >> 1. We use a weird custom backend and custom protocol extensions. >> >> This should definitely be replaced if it makes sense. It’s more urgent >> now that RHEL 6 is going EOL next year, and FAS 2 is still a Python >> 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS >> developers died a while ago… >> >> Naturally, the replacement is equally in a poor state, but may have >> some legs someday: https://github.com/fedora-infra/noggin >> >> 2. Ipsilon development was only considered important as part of being >> tech preview in RHEL and now it’s not. >> >> There are some major problems here. First of all, Ipsilon development >> has been gated by a single person. That person also seems to have >> trouble making time to review pull requests. There has been interest >> from the broader community about using and contributing to Ipsilon, >> since unlike Keycloak, it is written in an accessible language >> (Python). >> >> Getting Ipsilon to Python 3 would be enough for me to get started on >> bootstrapping some of the other interested parties onto Ipsilon, and >> hopefully give us a more sustainable community long-term. >> >> A final note here, I’m generally disappointed in how inaccessible >> infrastructure resources are to the broader community, and while a >> community OpenShift will alleviate some of that, I’m concerned that >> more sophisticated services would still require the crap workflow we >> have now for community vs infra. I’ve had thoughts about how to make >> that better on a broader basis, but that’s probably for another time… >> >> > > I don't know what is worse.. that if we try to improve things by saying we > can't maintain everything we are crap, or if we don't try to improve things > by maintaining stuff poorly we are crap. Do you want to beat us in the > morning or evening or just both times so you can work out your frustrations > on how badly we do stuff? Stephen, I respect your read and interpretation of what is written by Neal above. I also understand your lived experience. I think what Neal is getting at is that we don't have any knowledge yet about how the services we are looking for others (not infra team members) to run will be managed. The current system is less than desirable and what Neal is referencing. It'd be great to get more detail about how we are enabling these apps to be run by others so we can see what is possible. regards, bex ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 09:22, Neal Gompa wrote: > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon > wrote: > > > > There are two issues to unpack here: > > 1. We use a weird custom backend and custom protocol extensions. > > This should definitely be replaced if it makes sense. It’s more urgent > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > developers died a while ago… > > Naturally, the replacement is equally in a poor state, but may have > some legs someday: https://github.com/fedora-infra/noggin > > 2. Ipsilon development was only considered important as part of being > tech preview in RHEL and now it’s not. > > There are some major problems here. First of all, Ipsilon development > has been gated by a single person. That person also seems to have > trouble making time to review pull requests. There has been interest > from the broader community about using and contributing to Ipsilon, > since unlike Keycloak, it is written in an accessible language > (Python). > > Getting Ipsilon to Python 3 would be enough for me to get started on > bootstrapping some of the other interested parties onto Ipsilon, and > hopefully give us a more sustainable community long-term. > > A final note here, I’m generally disappointed in how inaccessible > infrastructure resources are to the broader community, and while a > community OpenShift will alleviate some of that, I’m concerned that > more sophisticated services would still require the crap workflow we > have now for community vs infra. I’ve had thoughts about how to make > that better on a broader basis, but that’s probably for another time… > > > I don't know what is worse.. that if we try to improve things by saying we can't maintain everything we are crap, or if we don't try to improve things by maintaining stuff poorly we are crap. Do you want to beat us in the morning or evening or just both times so you can work out your frustrations on how badly we do stuff? -- Stephen J Smoogen. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 4:13 PM Neal Gompa wrote: > > On Wed, Jul 17, 2019 at 10:09 AM Florian Weimer wrote: > > > > * Peter Robinson: > > > > >> > We posted this [1] blog today and want to open a mailing thread to > > >> > garner feedback, field questions and get some thoughts from the > > >> > Community on the approach that we in Community Platform Engineering > > >> > (CPE) are taking. > > >> > > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > > >> contracting, or is it up to every sub/side-project to host their mailing > > >> lists? > > >> > > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > > > I believe bugzilla is maintained by an internal team and as such is > > > outside of the CPE team's scope and hence unaffected. > > > > I strongly doubt this will be true indefinitely. I expect things will > > change pretty quickly once partners can access and file bugs in the > > other bug tracker. > > > > I’m assuming you are referring to Red Hat’s JIRA instance? > > (For shame that they’re using JIRA, but there’s nothing we can do about it…) I encourage us to focus on the rescoping work the infrastructure team is doing and identifying challenges/issues/means of support for that. A discussion of bug trackers is definitely nothing but rehashing old news. RH may or may not be changing the way it tracks bugs, but so far they haven't tried to deprecate any pathways Fedora uses. Matthew, Ben and I keep an eye on these things assisted by a literal metric ton of RHers who value and are passionate about Fedora. Bugzilla is currently maintained for us. If that changes we can react, but lets focus on what we know is changing now. regards, bex > > > > > > -- > 真実はいつも一つ！/ 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 -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ 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
Fedora-Rawhide-20190717.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all Failed openQA tests: 11/147 (x86_64), 18/18 (i386), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190716.n.0): ID: 422488 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/422488 ID: 422512 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/422512 ID: 422519 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/422519 ID: 422542 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/422542 ID: 422588 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/422588 ID: 422594 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/422594 ID: 422595 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/422595 Old failures (same test failed in Fedora-Rawhide-20190716.n.0): ID: 422469 Test: x86_64 Server-dvd-iso mediakit_repoclosure URL: https://openqa.fedoraproject.org/tests/422469 ID: 422478 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/422478 ID: 422493 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/422493 ID: 422497 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/422497 ID: 422501 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/422501 ID: 422525 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/422525 ID: 422608 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/422608 ID: 422609 Test: i386 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/422609 ID: 422610 Test: i386 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/422610 ID: 422611 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/422611 ID: 422612 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/422612 ID: 422613 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/422613 ID: 422614 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/422614 ID: 422615 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/422615 ID: 422616 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/422616 ID: 422617 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/422617 ID: 422618 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/422618 ID: 422619 Test: i386 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/422619 ID: 422620 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/422620 ID: 422621 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/422621 ID: 422622 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/422622 ID: 422623 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/422623 ID: 422624 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/422624 Soft failed openQA tests: 3/147 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20190716.n.0): ID: 422475 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/422475 ID: 422508 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/422508 ID: 422509 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/422509 Passed openQA tests: 133/147 (x86_64) Skipped non-gating openQA tests: 1 of 167 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.21 to 0.08 Previous test data: https://openqa.fedoraproject.org/tests/422050#downloads Current test data: https://openqa.fedoraproject.org/tests/422459#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.43 to 0.64 Previous test data
Re: Fedora 31 System-Wide Change proposal: No More i686 Kernels
I cross graded a laptop from i686 to x86_64 yesterday using dnf and it went pretty well without a reinstall. It also ran fine using an x86_64 kernel with i686 user space during the transition. I noticed that at least with using --forcearch=x86_64 that installing two packages that had names differing only in arch was a problem, even when there shouldn't have been file conflicts. So that to get an x86_64 kernel installed, I needed to install a different version than any of the installed i686 kernels. Initially I installed an x86_64 kernel and then booted into that. I assumed that x86_64 user space wouldn't work with an i686 kernel. (Though I didn't test that to be sure.) I didn't want an upgrade failing part way through, since it is a pain to clean up after that. Then I got of list of i686 packages (skipping noarch packages). After playing around with how to get dnf to do the update in one go (since it seemed likely to break things to have i686 libraries removed early) I found that using yum shell and swap worked. So you build a file with a swap line for each i686 to x86_64 conversion and then run yum shell with --forcearch=x86_64 specify that file and all the x86_64 packages get installed before the i686 packages get removed. I ran the process using screen to protect against desktop crashes and script to keep a record of what was done to check over afterwards. But it ran to completion without problems. wine is a special case. It couldn't be reinstalled in the mass cut over because it has dependencies on both x86_64 and i686 libs. So I had to reinstall afterwards. I'm not sure how dnf decides what the arch is. I still needed to use --forcearch when running an x86_64 kernel and an i686 user space. I rebooted after the userspace update and was able to reinstall wine properly without having to use --forcearch any more. So far things seem to be working normally, though in theory there might be some data that needs to get updated for an application. This went a lot smoother than I was expecting. I have had worse experiences updating after mass rebuilds than this one. Most of the articles on switching arches without full reinstalls are very old and describe more complicated processes. So I wanted to get something out there for other people that might have systems they want to switch over. ___ 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
Fedora rawhide compose report: 20190717.n.0 changes
OLD: Fedora-Rawhide-20190716.n.0 NEW: Fedora-Rawhide-20190717.n.0 = SUMMARY = Added images:5 Dropped images: 0 Added packages: 1 Dropped packages:1 Upgraded packages: 87 Downgraded packages: 1 Size of added packages: 519.87 KiB Size of dropped packages:951.72 KiB Size of upgraded packages: 8.48 GiB Size of downgraded packages: 23.45 KiB Size change of upgraded packages: 181.38 MiB Size change of downgraded packages: -118 B = ADDED IMAGES = Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190717.n.0.s390x.vmdk Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190717.n.0.s390x.qcow2 Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20190717.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190717.n.0.s390x.raw.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190717.n.0.s390x.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: gnome-network-displays-0.90.1-0.fc31 Summary: Stream the desktop to Wi-Fi Display capable devices RPMs:gnome-network-displays Size:519.87 KiB = DROPPED PACKAGES = Package: python-tahrir-0.9.2-6.fc30 Summary: A pyramid app for issuing your own Open Badges RPMs:python2-tahrir Size:951.72 KiB = UPGRADED PACKAGES = Package: NetworkManager-fortisslvpn-1.3.90-1.fc31 Old package: NetworkManager-fortisslvpn-1.2.10-1.fc31 Summary: NetworkManager VPN plugin for Fortinet compatible SSLVPN RPMs: NetworkManager-fortisslvpn NetworkManager-fortisslvpn-gnome Size: 837.70 KiB Size change: 166.57 KiB Changelog: * Tue Jul 16 2019 Lubomir Rintel - 1.3.90-1 - Update to 1.4-rc1 Package: R-coda-0.19.3-1.fc31 Old package: R-coda-0.19.2-2.fc30 Summary: Output Analysis and Diagnostics for MCMC RPMs: R-coda Size: 346.73 KiB Size change: 3.92 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 0.19.3-1 - Update to latest version Package: R-deldir-0.1.22-1.fc31 Old package: R-deldir-0.1.21-1.fc31 Summary: Delaunay Triangulation and Dirichlet (Voronoi) Tessellation RPMs: R-deldir Size: 1.35 MiB Size change: 2.51 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 0.1.22-1 - Update to latest version Package: R-ellipsis-0.2.0.1-1.fc31 Old package: R-ellipsis-0.2.0-1.fc31 Summary: Tools for Working with '...' RPMs: R-ellipsis Size: 246.93 KiB Size change: 1.54 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 0.2.0.1-1 - Update to latest version Package: R-future-1.14.0-1.fc31 Old package: R-future-1.13.0-1.fc31 Summary: Unified Parallel and Distributed Processing in R for Everyone RPMs: R-future Size: 604.10 KiB Size change: 18.07 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 1.14.0-1 - Update to latest version Package: R-git2r-0.26.1-1.fc31 Old package: R-git2r-0.25.2-2.fc31 Summary: Provides Access to Git Repositories RPMs: R-git2r Size: 2.66 MiB Size change: 70.92 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 0.26.1-1 - Update to latest version Package: R-pillar-1.4.2-1.fc31 Old package: R-pillar-1.4.1-1.fc31 Summary: Coloured Formatting for Columns RPMs: R-pillar Size: 191.82 KiB Size change: 3.57 KiB Changelog: * Tue Jul 16 2019 Elliott Sales de Andrade - 1.4.2-1 - Update to latest version Package: SDL2_image-2.0.5-1.fc31 Old package: SDL2_image-2.0.4-2.fc30 Summary: Image loading library for SDL RPMs: SDL2_image SDL2_image-devel Size: 564.45 KiB Size change: 46.83 KiB Changelog: * Tue Jul 16 2019 Pete Walter - 2.0.5-1 - Update to 2.0.5 Package: argbash-2.8.1-3.fc31 Old package: argbash-2.8.1-1.fc31 Summary: Bash argument parsing code generator RPMs: argbash Size: 55.86 KiB Size change: -1.81 KiB Changelog: * Mon Jul 01 2019 Stephen Gallagher - 2.8.1-2 - Fix python package version to work with EPEL 7 * Tue Jul 16 2019 Stephen Gallagher - 2.8.1-3 - Fix bash completion directory Package: black-hole-solver-1.4.0-1.fc31 Old package: black-hole-solver-1.2.1-1.fc31 Summary: The Black Hole Solitaire Solver Executable RPMs: black-hole-solver libblack-hole-solver-devel libblack-hole-solver1 Size: 278.30 KiB Size change: 3.77 KiB Package: blitz-1.0.1-4.fc31 Old package: blitz-1.0.1-3.fc30 Summary: C++ class library for matrix scientific computing RPMs: blitz blitz-devel blitz-doc Size: 2.36 MiB Size change: -80.64 KiB Changelog: * Tue Jul 16 2019 Sergio Pascual - 1.0.1-4 - Patch to use python2 instead of python Package: breeze-gtk-5.16.3-2.fc31 Old package: breeze-gt
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, 17 Jul 2019 at 10:09, Florian Weimer wrote: > * Peter Robinson: > > >> > We posted this [1] blog today and want to open a mailing thread to > >> > garner feedback, field questions and get some thoughts from the > >> > Community on the approach that we in Community Platform Engineering > >> > (CPE) are taking. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. > > I think the word unaffected means something different in what Peter was trying to communicate. It is 'unaffected' by our plans in the same way that we can't easily affect the weather in Brazil. Thus it is not in the scope of things we can say we are ending, adding, changing, moving to a PDP-11 cluster in Devonshire, etc. > Thanks, > Florian > ___ > 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 > -- Stephen J Smoogen. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 10:09 AM Florian Weimer wrote: > > * Peter Robinson: > > >> > We posted this [1] blog today and want to open a mailing thread to > >> > garner feedback, field questions and get some thoughts from the > >> > Community on the approach that we in Community Platform Engineering > >> > (CPE) are taking. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. > I’m assuming you are referring to Red Hat’s JIRA instance? (For shame that they’re using JIRA, but there’s nothing we can do about it…) -- 真実はいつも一つ！/ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 03:20:34PM +0200, Florian Weimer wrote: > * Peter Robinson: > > >> > We posted this [1] blog today and want to open a mailing thread to > >> > garner feedback, field questions and get some thoughts from the > >> > Community on the approach that we in Community Platform Engineering > >> > (CPE) are taking. > >> > >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > >> contracting, or is it up to every sub/side-project to host their mailing > >> lists? > >> > >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > > > I believe bugzilla is maintained by an internal team and as such is > > outside of the CPE team's scope and hence unaffected. > > I strongly doubt this will be true indefinitely. I expect things will > change pretty quickly once partners can access and file bugs in the > other bug tracker. You can have your doubts but what Peter said is true. CPE is not responsible for maintaining bugzilla, so it's very much out of our scope :) Pierre ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
* Peter Robinson: >> > We posted this [1] blog today and want to open a mailing thread to >> > garner feedback, field questions and get some thoughts from the >> > Community on the approach that we in Community Platform Engineering >> > (CPE) are taking. >> >> Sunsetting Mailman sounds pretty harsh. Will Red Hat do the >> contracting, or is it up to every sub/side-project to host their mailing >> lists? >> >> Bugzilla isn't mentioned. Has it been evaluated in this context? > > I believe bugzilla is maintained by an internal team and as such is > outside of the CPE team's scope and hence unaffected. I strongly doubt this will be true indefinitely. I expect things will change pretty quickly once partners can access and file bugs in the other bug tracker. Thanks, Florian ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 11:46 AM Pierre-Yves Chibon wrote: > > Good Morning, > > We posted this [1] blog today and want to open a mailing thread to garner > feedback, field questions and get some thoughts from the Community on > the approach that we in Community Platform Engineering (CPE) are taking. > > [1] > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ It would be useful to have the CPE mission linked to directly, it's mentioned a number of times in the post but I don't see a direct way to get to it. ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
> > We posted this [1] blog today and want to open a mailing thread to > > garner feedback, field questions and get some thoughts from the > > Community on the approach that we in Community Platform Engineering > > (CPE) are taking. > > Sunsetting Mailman sounds pretty harsh. Will Red Hat do the > contracting, or is it up to every sub/side-project to host their mailing > lists? > > Bugzilla isn't mentioned. Has it been evaluated in this context? I believe bugzilla is maintained by an internal team and as such is outside of the CPE team's scope and hence unaffected. Peter ___ 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
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon wrote: > > Good Morning, > > We posted this [1] blog today and want to open a mailing thread to garner > feedback, field questions and get some thoughts from the Community on > the approach that we in Community Platform Engineering (CPE) are taking. > > [1] > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > Two things that concern me at this time: > Mailman/Hyperkitty/postorious — Maintaining this stack has cost the equivalent > of an entire developer’s time long-term. However, we recognize the imperative > that projects have mailing lists for discussion and collaboration. No further > features will be added here and based on the community needs an outside > mailing list service can be contracted. I really don’t think this is true anymore. It *is* annoying that the packaging is still *not* in Fedora, so other people can’t help with making sure that software stays up to date, but this should be fixable. I’m happy to co-maintain packages in Fedora+EPEL for mailman3, hyperkitty, and postorius. However, no one has submitted the latter two for review. The mailman 3 stack is starting to see broader adoption. I’ve seen a number of RH and non-RH projects alike deploy and use it. It’s slow, but it’s growing in use. They’re not even hard to find if you know some Google-fu. “An outside mailing list service can be contracted” doesn’t make any sense for a project that does close to 70% of its communication via mailing lists. This does not make sense at all, and I would say this should move from category 3 to category 2 *at least*. Again, I’m personally willing to help with keeping the software packages up to date provided someone puts in the initial effort to get them into Fedora + EPEL. I know the packaging exists and is being maintained externally somewhere, so it should be no challenge to upstream them into Fedora. > Ipsilon — Ipsilon is our identity provider. It supports multiple > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …) > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…). > While it was originally shipped as a tech preview in RHEL it no longer is and > the team working on this application has also been refocused on other > projects. > We would like to move all our applications to use OpenID Connect or SAML 2.0 > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an > IPA-based solution, which in turn allows us to replace ipsilon by a more > maintained solution, likely Red Hat Single Sign On. The dependencies > are making this a long term effort. We will need to announce to the community > that this means we will shut down the public OpenID 2.0 endpoints, > which means that any community services that use this protocol need > to be moved to OpenID Connect as well. There are two issues to unpack here: 1. We use a weird custom backend and custom protocol extensions. This should definitely be replaced if it makes sense. It’s more urgent now that RHEL 6 is going EOL next year, and FAS 2 is still a Python 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS developers died a while ago… Naturally, the replacement is equally in a poor state, but may have some legs someday: https://github.com/fedora-infra/noggin 2. Ipsilon development was only considered important as part of being tech preview in RHEL and now it’s not. There are some major problems here. First of all, Ipsilon development has been gated by a single person. That person also seems to have trouble making time to review pull requests. There has been interest from the broader community about using and contributing to Ipsilon, since unlike Keycloak, it is written in an accessible language (Python). Getting Ipsilon to Python 3 would be enough for me to get started on bootstrapping some of the other interested parties onto Ipsilon, and hopefully give us a more sustainable community long-term. A final note here, I’m generally disappointed in how inaccessible infrastructure resources are to the broader community, and while a community OpenShift will alleviate some of that, I’m concerned that more sophisticated services would still require the crap workflow we have now for community vs infra. I’ve had thoughts about how to make that better on a broader basis, but that’s probably for another time… -- 真実はいつも一つ！/ 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
Re: Discussion around app retirements and categorizations by the CPE team
* Pierre-Yves Chibon: > We posted this [1] blog today and want to open a mailing thread to > garner feedback, field questions and get some thoughts from the > Community on the approach that we in Community Platform Engineering > (CPE) are taking. Sunsetting Mailman sounds pretty harsh. Will Red Hat do the contracting, or is it up to every sub/side-project to host their mailing lists? Bugzilla isn't mentioned. Has it been evaluated in this context? Thanks, Florian ___ 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
Discussion around app retirements and categorizations by the CPE team
Good Morning, We posted this [1] blog today and want to open a mailing thread to garner feedback, field questions and get some thoughts from the Community on the approach that we in Community Platform Engineering (CPE) are taking. [1] https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ pingou - For the CPE team ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@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
