Re: Red Hat & Fedora -- largely stepping out of this ecosystem
contributors to the Hyperscale SIG are also supporting work on Fedora Asahi and Fedora ELN just as fast! ( I am looking at you Davide and Neal). I am betting on the community to welcome the clones and help them find their dividing lines as well as accept their fixes and assist them in their CI and validations. This Red Hat decision didn't exclude the clones, it just made the fact that the bar has been set higher for community participation a more clearly defined action IMO. > > I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a > professional level. Obviously, I'll do what I need to do to help make > my employer successful -- but when a choice exists, Fedora/CentOS/RHEL > won't be where I land going forward. So I am terribly surprised by the statement that you won't be coming with us. I see you as someone who could really help the clones be a part of the community and help them navigate the early introduction into the CentOS Stream and ELN communities. If you ever decide to return as a Fedora/CentOS/RHEL user for your own reward, I'll be in the line that welcomes you back and looks forward to your help. -- David Duncan ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up! Nforro's awscli2 is working. It's time to retire the awscli
Thanks Neal! Responding inline, but from gmail, so it's not as pretty as I would like. On Sat, May 13, 2023 at 2:15 PM Neal Gompa wrote: > On Sat, May 13, 2023 at 3:02 PM David Duncan wrote: > > > > Now that awscli2 is out and functional. Gwyn and I are thinking it's > time to retire the original awscli package in favor of this one. We are > thinking that it will be best to keep the awscli (v1) maintained until the > release of F39 later this year and retire it from the active releases it at > that time. If there is anyone taking a dependency here that thinks that > they will need more time, please let us know. > > > > Do you mean that we would want to have a Change proposal to retire it > for F39? That's what it sounds like... > Yes. I would say that is what is needed. I'll create that change proposal. > > > Nikola is working directly with Kyle Knapp, the cli developer at > Amazon, on the python-awscrt (common c runtime libs) and the awscli2 and > making great progress on getting a packit configuration in the upstream > source for automating test runs and builds. It's definitely the better > model. > > > > Note that python-awscrt links to AWS CRT crypto libraries, which can > be an issue when it comes to respecting system crypto policies. It > would be good to have that resolved too... > I believe that Nikola is linking to the system libraries, similar to the way we did it in the original submission. We had a reasonably long conversation on that when he created the review. > > > Ultimately, I think that awscli should be an alias to the awscli. > > I'm not sure what you mean here? When we retire the awscli (the v1) I thought it would be beneficial to ensure that there is a "Provides: awscli" in the awscli2, but it's actually already there. I forgot and didn't look before I spoke. It's there, so ignore this bit. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up! Nforro's awscli2 is working. It's time to retire the awscli
Now that awscli2 is out and functional. Gwyn and I are thinking it's time to retire the original awscli package in favor of this one. We are thinking that it will be best to keep the awscli (v1) maintained until the release of F39 later this year and retire it from the active releases it at that time. If there is anyone taking a dependency here that thinks that they will need more time, please let us know. Nikola is working directly with Kyle Knapp, the cli developer at Amazon, on the python-awscrt (common c runtime libs) and the awscli2 and making great progress on getting a packit configuration in the upstream source for automating test runs and builds. It's definitely the better model. Ultimately, I think that awscli should be an alias to the awscli. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: EC2 AMIs default to the gp3 EBS volume type (Self-Contained Change proposal)
> ...snip... > > > I think this is a great idea and we should do it, but I have some > questions. :) > > We currently use 'fedimg' to upload ami images, and it currently uploads gp2 > and 'standard' images. Do we need to then modify fedimg to upload gp3? > I am working on replacing the current version of fedimg to move from libcloud to boto3. The plan is to provide the updated version for this release. ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Allow non-packagers to push to dist-git forks without fedpkg
> On Apr 22, 2022, at 6:44 AM, Miro Hrončok wrote: > > Hello folks, > > what would it take to allow non-packagers to push to dist-git forks without > fedpkg? > > The instructions at > https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager > assume they run Fedora (or another distro with fedpkg), but this is > extremely unfriendly to contributors who run other distros. > > The alternative is external pull request which is awesome in theory but quite > tedious in practice. E.g. as a package maintainer, I cannot push my changes > to a proposed external pull request. > > If I understand correctly, SSH access is a security/legal/whatever no-go for > nonpackagers, but can we offer some kind of standard git mechanism to > authenticate? API tokens maybe? > > If not, can we at least extract the fedpkg bits that do this and release that > as a standalone easy-to-install software that we can offer or even package to > other distributions? > As frequently as I find myself working in a different environment due to various constraints, having the fedpkg bits available in other environments — even homebrew — sounds like a win in my opinion. signature.asc Description: Message signed with OpenPGP ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> On Apr 7, 2022, at 2:31 AM, Neal Gompa wrote: > > On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann wrote: >> >> Hi, >> >>> On the cloud side, it's been very difficult to articulate any benefits >>> for supporting UEFI when the majority of the consumers of Fedora Cloud >>> don't have any pressing need to do it and things like hibernation and >>> snapshotting are non-functional. Last year, I changed Fedora Cloud to >>> hybrid boot[6] so that our image artifacts support both boot modes. >> >> Any chance for regular anaconda installs doing a hybrid boot setup too? >> >> The installed systems will look pretty much the same (gpt with both >> bios-boot and efi-esp partition) no matter how they where installed, >> and it'll be trivial to switch from BIOS to UEFI without reinstalling >> the system. >> >> We can fade out some stuff already (mbr support), and painless switching >> to UEFI for systems which where installed in BIOS mode for whatever >> reason should also help UEFI adaption. >> > > Anaconda can absolutely do it, after all, the cloud image build > currently runs Anaconda (!!!) to build the image. > > In this scenario, grub2-pc, shim, and grub2-efi always get installed, > too. This became possible with the unified config introduced in Fedora > Linux 34. > > The problem is that right now Anaconda has some hardwired assumptions > about what kind of bootloader and partitioning to request for all the > default partitioning modes. It shouldn't be difficult to fix, though. > Additionally, by switching to GPT by default for everything, we > probably want to replace inst.gpt with inst.mbr for forcing legacy > MBR. > > If we did this now (in F37), we could then more easily fade out BIOS > support when the adoption curve is better off. > And this is exactly what we need in my opinion. It sounds like there has been a great deal of thought put into what the developers can manage on the supporting team, but it also appears that issues have prevented direct contribution based on some sort of misconfiguration in the repository, though it sounds like this is fixed as of this discussion. It still speaks to more than a year of complication in contribution. Is Neal really the only one who was impacted by the inability to submit a PR? I think that creating choice is the right response and that’s exactly why we created a dually supported boot model in the cloud (soon-to-be-edition again) working group (thank you Neal and Gerd). Choice is our best tool in the freedom toolkit. I have heard many say that there is no rush to remove support for hardware that is in use by those of the community that may not be capable of switching. I would like to see a period of joint support in Fedora with the promise that the legacy-bios support will be removed when it no longer serves the community, but not before that time is clear. It obviously does have an end date consistent with F37 release. VMware’s deprecation does not set a date. It sets the promise of announcing a date at a later time. I think we should follow suit. A future, as yet undetermined, Fedora release will not have legacy-bios and we understand that it is expected to follow a concerted effort to make moving to UEFI as easy as possible. If you have to fallback, there should be an immediately available option like Gerd and Neal have implemented in their changes. In the meantime, this is obviously going to require a rally of community support. As a community, we are going to have to limit the amount of explaining we need to do. To loosely quote the agile manifesto: It is better to focus on working code than to focus on comprehensive documentation. I see that as a directive to ship support for both boot models in all editions for at the very least, one release and better to provide a minimum of two. - David ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> On Apr 5, 2022, at 8:08 AM, Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS >> >> == Summary == >> Make UEFI a hardware requirement for new Fedora installations on >> platforms that support it (x86_64). Legacy BIOS support is not >> removed, but new non-UEFI installation is not supported on those >> platforms. This is a first step toward eventually removing legacy >> BIOS support entire >> >> == Owner == >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří >> Konečný]], [[User:bcl| Brian C. Lane]] >> * Email: rharw...@redhat.com >> >> >> == Detailed Description == >> UEFI is defined by a versioned standard that can be tested and >> certified against. By contrast, every legacy BIOS is unique. Legacy >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) >> and on its way out. As it ages, maintainability has decreased, and >> the status quo of maintaining both stacks in perpetuity is not viable >> for those currently doing that work. >> >> It is inevitable that legacy BIOS will be removed in a future release. >> To ease this transition as best we can, there will be a period (of at >> least one Fedora release) where it will be possible to boot using the >> legacy BIOS codepaths, but new installations will not be possible. >> While it would be easier for us to cut support off today, our hope is >> that this compromise position will make for a smoother transition. >> Additional support with issues during the transition would be >> appreciated. >> >> While this will eventually reduce workload for boot/installation >> components (grub2 reduces surface area, syslinux goes away entirely, >> anaconda reduces surface area), the reduction in support burden >> extends much further into the stack - for instance, VESA support can >> be removed from the distro. >> >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore >> mandates that machines must have been made after 2006). Like the >> already accepted Fedora 37 change to retire ARMv7 support, the >> hardware targeted tends to be rather underpowered by today’s >> standards, and the world has moved on from it. Intel stopped shipping >> the last vestiges of BIOS support in 2020 (as have other vendors, and >> Apple and Microsoft), so this is clearly the way things are heading - >> and therefore aligns with Fedora’s “First” objective. >> >> == Feedback == >> Dropping legacy BIOS was previously discussed (but not proposed) in 2020: >> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ >> >> Important, relevant points from that thread (yes, I reread the entire >> thread) that have informed this change: >> >> * Some machines are BIOS-only. This change does not prevent their use >> yet, but they are effectively deprecated. grub2 (our default >> bootloader) is already capable of both BIOS and UEFI booting. >> * Drawing a clear year cutoff, let alone a detailed list of hardware >> this change affects, is basically impossible. This is unfortunate but >> unlikely to ever change. >> * There is no migration story from Legacy BIOS to UEFI - >> repartitioning effectively mandates a reinstall. As a result, we >> don’t drop support for existing Legacy BIOS systems yet, just new >> installations. >> * There is no way to deprecate hardware without causing some amount of >> friction. >> * While at the time AWS did not support UEFI booting, that is no >> longer the case and they support UEFI today. >> >> == Benefit to Fedora == >> UEFI is required for many desirable features, including applying >> firmware updates (fwupd) and supporting SecureBoot. As a standalone >> change, it reduces support burden on everything involved in installing >> Fedora, since there becomes only one way to do it per platform. >> Finally, it simplifies our install/live media, since it too only has >> to boot one way per arch. Freedom Friends Features First - this is >> that last one. >> >> == Scope == >> * Proposal owners: >> ** bootloaders: No change (existing Legacy BIOS installations still >> supported). >> ** anaconda: No change (there could be only optional cleanups in the >> code). However, it needs to be verified. >> ** Lorax: Code has already been written: >> https://github.com/weldr/lorax/pull/1205 >> > > This pull request primarily drops legacy BIOS support by dropping > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > support there if we reuse GRUB there too. Other distributions > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on > live media. > >> * Other developers: >> ** libvirt: UEFI works today, but is not the default. UEFI-only >> installation is needed for Windows 11, and per conversations, libvirt >> is prepared for this change. >> ** Virtualbox: UEFI Fedora installs are working and per virtualbox >> team, UEFI will be
Re: [Test-Announce] Fedora Linux 36 Beta is GO
> On Mar 24, 2022, at 2:44 PM, Richard Shaw wrote: > > On Thu, Mar 24, 2022 at 3:35 PM Dusty Mabe wrote: > > > On 3/24/22 15:46, Richard Shaw wrote: > > On Thu, Mar 24, 2022 at 2:40 PM David Duncan > <mailto:davd...@gmail.com>> wrote: > > > > Hi, > > > > > On Mar 24, 2022, at 12:28 PM, Richard Shaw > <mailto:hobbes1...@gmail.com>> wrote: > > > > > > I may try increasing the virtual disk size as I assumed 8GB was > > enough just to play around, but why is it trying to allocate space for swap > > when it should be using zswap? > > > > > > > Are you sure that it is a function of the Virtualbox image? If you > > think it still is, can you file an issue for cloud-sig? > > > > > > Did the screenshot come through? I'm not sure I understand the question. > > VirtualBox seems to default to 8GB VDI image for Linux. I thought it was a > > bit low but figured it was worth trying. I upped the VDI image to 20GB and > > the install completed. > > > > After install I did confirm that no swap partition/file was created. > > Perhaps this is an artifact left over in the installer prior to the move to > > zswap and should be removed? > > > > I think David was assuming you were using the Vagrant Virtualbox image > provided by the Cloud working group. > > It looks like you are doing an Anaconda install, so not using the Vagrant > image. > > Ok, yes, I was doing a typical Workstation ISO install. Sorry about that Richard. Sorry about that. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] Fedora Linux 36 Beta is GO
Hi, > On Mar 24, 2022, at 12:28 PM, Richard Shaw wrote: > > I may try increasing the virtual disk size as I assumed 8GB was enough just > to play around, but why is it trying to allocate space for swap when it > should be using zswap? > Are you sure that it is a function of the Virtualbox image? If you think it still is, can you file an issue for cloud-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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
Peter Robinson writes:
> On Wed, Jan 5, 2022 at 2:09 PM Neal Gompa wrote:
>>
>> On Wed, Jan 5, 2022 at 9:05 AM Ben Cotton wrote:
>> >
>> > https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
>> >
>> > == Summary ==
>> > Do not not include NetworkManager support for legacy network
>> > configuration files by in new installations.
>> >
>> > == Owner ==
>> > * Name: [[User:Lkundrak| Lubomir Rintel]]
>> > * Email:
>> >
>> > * Name: Ana Cabral
>> > * Email:
>> >
>> > * Name: [[User:Thaller| Thomas Haller]]
>> > * Email:
>> >
>> > == Detailed Description ==
>> > Long ago, network was configured using "network" service.
>> > It was essentially a set of shell scripts, that sourced snippets of
>> > configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
>> > files").
>> > The ifcfg files compatible with the legacy network service were kept
>> > when NetworkManager was intruduced.
>> >
>> > As the NetworkManager feature set was expanding beyond what the legacy
>> > network service could support,
>> > the ifcfg files written by NetworkManager could no longer be
>> > guarranteed to be compatible.
>> > NetworkManager eventually gained support for connection types
>> > completely unknown to the legacy network service
>> > and ended up using a more streamlined configuration file format for
>> > those, known as keyfile.
>> >
>> > NetworkManager's use of various configuration files is, in fact,
>> > configurable and extensible with plugins.
>> > Prior to Fedora 33, NetworkManager by default was configured to enable
>> > both ifcfg files and keyfiles, with the former taking precedence when
>> > possible.
>> > The precedence changed in
>> > [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
>> > Fedora 33] to perfer keyfile.
>> >
>> > The precedence has an effect when a network connection profile is created.
>> > Once the connection profile exists, NetworkManager is unable to
>> > convert the profile to a different configuration backend.
>> > This makes it necessary for NetworkManager to support the same feature
>> > set in all configuration backend.
>> > Given the complexities stemming from historical legacy of ifcfg files
>> > not being designed (or documented) in a
>> > particularly forward-looking way, this has been a huge and complex
>> > effort with all the downsides:
>> > The ifcfg support code is huge (130K lines, not counting the enormous
>> > test suite) and has constantly been a source of bugs.
>> >
>> > == Benefit to Fedora ==
>> > This change removes a body of code that has a large cost in terms of
>> > bugs and maintenance at questionable benefit.
>> >
>> > It slightly reduces the default installation size.
>> >
>> > == Scope ==
>> > * Proposal owners: Split the ifcfg plugin into a subpackage package.
>> > Make sure the ifcfg plugin stays on upgrades. Provide a migration
>> > tool.
>> >
>> > * Other developers: N/A
>> >
>> > * Release engineering: N/A
>> >
>> > * Policies and guidelines: N/A
>> >
>> > * Trademark approval: N/A
>> >
>> > * Alignment with Objectives: N/A
>> >
>> > == Upgrade/compatibility impact ==
>> > For the time being the ifcfg plugin is kept around, albeit in a
>> > sub-package that's not included in new installations.
>> > The appropriate RPM tags will ensure the sub-package with the ifcfg
>> > plugin will be installed on upgrades.
>> > A migration tool will be provided for users who'd like to remove the
>> > legacy package from their systems after upgrade.
>> >
>> > == How To Test ==
>> > N/A.
>> > The keyfiles are used by default in Fedora 33 already, so any problem
>> > with them would've already been spotted.
>> >
>> > == User Experience ==
>> > Regular users will not notice anything.
>> > Users of old installations with ifcfg files will get the new
>> > sub-package on upgrade.
>> > New systems will default to use keyfiles, which is not something
>> > regulars user would notice.
>> >
>> > System integrators and administrators might use tools that drop in
>> > ifcfg files during automated installations (e.g. via kickstart or a
>> > configration management tool).
>> > They will need to update their tools -- convert the ifcfg files to
>> > keyfiles or include the ifcfg sub-package.
>> >
>> > == Dependencies ==
>> > N/A
>> >
>> > == Contingency Plan ==
>> > * Contingency mechanism: If it turns out we can't drop support for
>> > ifcfg files by default, we can either fold the ifcfg sub-package back
>> > into the main NetworkManager package or make sure it is included in
>> > new installations (via comps change).
>> > * Contingency deadline: Any time.
>> > * Blocks release? No.
>> >
>> > == Documentation ==
>> > We'll need to write the documentation for the migration tool.
>> > Perhaps also something the sysadmins wondering why their ifcfg files
>> > don't work anymore could find and refer to.
>> >
>> > TODO: Update this once it's done.
>> >
>> > == Release Notes ==
>> > We'll need to include a paragraph about this in the release notes.
>> >
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jun 09, 2021 at 06:52:40AM -0000, David Duncan wrote: > > Bumping this for technical discussion. We are planning to put this in > action if there are no technical objections. > > Please wait until the FESCo has approved the Change. > I made that sound like an imperative. That was a mistake. I wanted to redirect the thread to technical review instead of program concerns. Of course no actual implementation will be done without approval. ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
Bumping this for technical discussion. We are planning to put this in action if there are no technical objections. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libravatar ported to Fedora's AWS
Great News! Much appreciated! David Duncan http://about.me/davdunc On Wed, Mar 17, 2021 at 9:37 PM Christoph Karl wrote: > > Am 14.03.21 um 23:32 schrieb clime: > > Hello, > > > > I have just finished port of libravatar.org service to server provided > > by Fedora. Big thanks to the Fedora project for sponsoring libravatar. > > Avatars in pagure.io, src.fp.o, Bodhi should now load much faster. > > +1 > > Christoph > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging
On Tue, Jun 9, 2020 at 4:08 PM Dan Čermák wrote: > > Hi Ankur, > > Ankur Sinha writes: > > > Hi folks, > > > > The packaging team is generally quite stretched, and we frankly need > > more people helping us out. > > > > The main issue with newcomers taking on packaging is that the learning > > curve here is much more technical then a lot of other areas in Fedora. > > So, while it is still expected that folks read the docs and learn things > > themselves, perhaps we could be more active in helping them? > > That is true, getting into packaging is not easy at all. > > Besides improving existing docs, how about having a individual packagers > helping out newcomers in 1:1 chats, e.g. on IRC or Jitsi? > +1 on the individual participation for mentoring. My difficulties are specific and typically I find a helpful hint in the classroom content, but then it moves in an abstract way and I am lost in trying to follow bugs upstream and matching the speed of my colleagues who are much better at packaging who just take over the duties and leave me with nothing to do. > > > > We've had rpm packaging classroom sessions in the past. Are any folks > > interested in restarting these? Maybe a different SIG could do a session > > each month to help newcomers get started with packaging their tools? > > Sponsors, what do you think? > > > > -- ___ 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
