Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Thu, Apr 25, 2024 at 11:42:57AM +0200, Jan Kolarik wrote: > upgrades from F41 to F42. Before executing the system-upgrade, users are > anyway advised to ensure that all installed packages are fully updated. I don't believe GNOME Software enforces this. (There was some debate about whether doing two updates in a row was really useful, if I remember.) That may be a big source of pain. -- Matthew Miller Fedora Project Leader -- ___ 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: SPDX Statistics - L'Aigle meteorite edition
On Fri, Apr 26, 2024 at 08:20:43PM +0200, Miroslav Suchý wrote: > Graph of these data with the burndown chart: > > https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing [...] > New projection when we will be finished is 2025-04-06 (+5 days from last > report). Pure linear approximation. Just eyeballing the prediction graph in the Google doc, it looks like the linear approximation is distorted by the big drop in "non-trivial" last September. And, the slope for "converted" is pretty steep before that, but significantly flatter after. I think this is making the prediction a little too optimistic. If we extrapolate linearly just from 2023-09-29 on, that gives an end-date of 2026-02-22. And linearly is probably optimistic too, given the classic "last 10% is 90% of the time" thing. On the other hand, if we have some other big conversion efforts (like a virtual hackfest or something), maybe factoring in a big jump _is_ right. -- Matthew Miller Fedora Project Leader -- ___ 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
Announcing Fedora Linux 40
Fedora Linux 40 is now officially available. Read the details in our Fedora Magazine article at: * https://fedoramagazine.org/announcing-fedora-linux-40 or download installer images from: * https://fedoraproject.org/ or, of course, simply upgrade your already-installed systems, which shouldn't take much longer than ordering and consuming your favorite hot and possibly caffeinated beverage. If you run into any trouble, or just have questions, you can find help at * https://ask.fedoraproject.org/ There are several important release-day bugfix and security updates available today as well. If you upgrade from an earlier Fedora Linux release, you'll get them as part of that. For new systems, please make sure to check for and apply updates as soon as possible. -- Matthew Miller Fedora Project Leader -- ___ 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
Announcing Fedora Linux 40
Fedora Linux 40 is now officially available. Read the details in our Fedora Magazine article at: * https://fedoramagazine.org/announcing-fedora-linux-40 or download installer images from: * https://fedoraproject.org/ or, of course, simply upgrade your already-installed systems, which shouldn't take much longer than ordering and consuming your favorite hot and possibly caffeinated beverage. If you run into any trouble, or just have questions, you can find help at * https://ask.fedoraproject.org/ There are several important release-day bugfix and security updates available today as well. If you upgrade from an earlier Fedora Linux release, you'll get them as part of that. For new systems, please make sure to check for and apply updates as soon as possible. -- Matthew Miller Fedora Project Leader -- ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote: > > This should have been an announced Change. This is a significant > > change with wide impact. > > I've filed a bug, proposed it as a blocker, and filed a FESCo ticket > asking FESCo to designate the bug as a blocker. > > https://bugzilla.redhat.com/show_bug.cgi?id=2274830 > https://pagure.io/fesco/issue/3196 I admit I was also initially surprised. But, this actually has been going through the Change process for a while: F33: https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile That last one actually says: > The upstream NetworkManager project has recently declared the ifcfg plugin > as deprecated. This means that the code will only receive bug fixes, and > will not get new functionality such as supporting new properties. > > With this change, existing profiles in ifcfg format will be automatically > migrated to the native keyfile format via a migration service shipped with > the NetworkManager-initscripts-ifcfg-rh package. In Fedora, we plan to > drop the plugin by Fedora Linux 41. (Emphasis on the last line.) The words "the network-scripts subpackage is deprecated and will be removed" do not seem to have appeared in the release notes, and in retrospect that probably should have been stronger. "Gone in 40" _does_ technically fit into the letter of "drop by 41"... but maybe not the spirit? I think a "drop in 41" change (and a clear item in the F40 release notes!) is probably the best way to clear the air -- but I don't think the maintainers stepped around the process here. -- Matthew Miller Fedora Project Leader -- ___ 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: xz backdoor
On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote: > It does bring up a potential point that perhaps > Fedora should have an additional repo (let's > call it "emergency fixes") that is not community > mirrored (so any mirrors for load sharing > would be fully controlled by the project), with > a short refresh time, and containing only > packages that need to get out immediately. > If a critical fix needs to get out to the > community it could be (almost) immediately > available. After a few days (when public > mirrors would be expected to have updated) > those packages could be removed (reducing > the load on this repo). For the next time, of > course (and there will be a next time, there > is always a next time). https://pagure.io/releng/issue/5886 (This was after Heartbleed, FWIW.) > -- > ___ > 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 -- Matthew Miller Fedora Project Leader -- ___ 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: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote: > Unit tests are something for upstream developers. They should NEVER be run > in a distribution build. Even in the few little packages I'm still responsible for, I sometimes see unit test failures. The developer ran the tests, but not on S390. Or, with a different timezone database than current in Fedora. Or etc. -- Matthew Miller Fedora Project Leader -- ___ 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: Orphaning all my packages
On Tue, Oct 03, 2023 at 04:36:20PM +0200, Michael J Gruber wrote: > Thank you for all the effort you have put into maintaining these > packages so far, for the benefit of all of Fedora, and consequently > its downstream! Indeed -- thank you Todd. -- Matthew Miller Fedora Project Leader ___ 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: The new Change discussion process is painful
On Wed, Sep 13, 2023 at 04:32:34PM -0300, Tulio Magno Quites Machado Filho wrote: > I've been trying this, but Discourse reverted part of my settings without > any warnings after a few months. > > I raised the issue here: > https://discussion.fedoraproject.org/t/discourse-dropped-an-email-address-from-my-preferences-today/89614 > > I still do not understand what happened 2 days ago. Sorry, I missed that -- the infrastructure team doesn't actually handle Discourse. I'll respond to you there. -- Matthew Miller Fedora Project Leader ___ 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: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 09:20:09AM -0700, Adam Williamson wrote: > IIRC it was a condition of that proposal that we wind up on a hosted > version of the *open source* release of gitlab, which is something we > managed to talk gitlab into doing for us. IMBW, though, it was a while > ago. Short version is: yes, we did talk them into that with an informal plan, and then someone higher up at gitlab pulled the plug on the idea. At this point, we need to step back and re-evaluate all of our options. I'm open to the idea of a revitalized pagure as one of the possibilities, but before I'd personally back that, I'd like to see it _really_ revitalized... it needs to be more than a heroic effort by a few people. Otherwise, we'll be back in the same place in few years. -- Matthew Miller Fedora Project Leader ___ 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: The new Change discussion process is painful
On Wed, Sep 13, 2023 at 09:08:57AM +0200, Remi Collet wrote: > Sadly it seems there is some email issues > > For a few days, tons of messages are lost > so, I also don't receive any of the recent change announcements > > BTW, I agree this dual channel is terrible for discussion > > I personally don't follow discussion.fpo > too much tools kills simplicity Everything is a balance. Even if you don't want to follow Fedora Discussion in general, to follow changes, you can go subscribe to just those by email. 1. Sign in you with your Fedora account 2. Complete creating a Discussion account if you haven't already 3. Go to https://discussion.fedoraproject.org/my/preferences/tracking 4. Remove everything from all of the Categores and Teams & Tags dropdowns that you don't want. (A few things are populated as defaults.) 5. Under Categories, add "Change Proposals" to either Watched (which will send a notification for every post) or Watching First Post (which does what it says). 6. Go to https://discussion.fedoraproject.org/my/preferences/emails 7. Change "Send me email when I have a notification" to "always", if it isn't already. 8. Optional: notification messages will set a List-Id corresponding to the Change Proposals category. You can set up your mail filters to do what you like with those. 9. To interact, you can either come to the Discussion web interface, or just reply to the email notifications. -- Matthew Miller Fedora Project Leader ___ 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: The new Change discussion process is painful
On Wed, Sep 13, 2023 at 12:19:05PM +0200, Sandro wrote: > On 13-09-2023 08:09, Adam Williamson wrote: > > From there, it's up to people where they see and respond to them. If > >more people are responding in discourse than on the mailing list, that > >would seem to suggest that there*is* a reason to announce things > >there... > > I'm quite sure Matthew (mattdm) would disagree with above statement. > The idea was/is, iirc, to only announce on both channels, but have > the discussion take place on Discourse. > > So, making this pick & mix is definitely not the intention and it > has already proven futile in a previous mishap. Right -- I really don't want to split the conversation. With the telemetry change, I didn't ask moderators here to take a heavy hand, because people had a lot they wanted to say and I didn't want to squash that. -- Matthew Miller Fedora Project Leader ___ 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 Change Proposal: Color Bash Prompt (System Wide)
On Sat, Jul 15, 2023 at 05:22:15PM +0200, Dan Čermák wrote: > > For a long time the Fedora default shell prompt has been monochrome, > > which makes it difficult to find shell prompt commands between long > > command outputs when scrolling through terminal shell output. > > This Change introduces a simple default colored shell prompt, which > > users can also easily theme themselves. > > > > [https://petersen.fedorapeople.org/color-bash-prompt.png screenshot of > > color bash prompt in gnome-terminal] > > I am overall in favor of this change, thanks for working on this Jens > and for keeping it simple! Me too! -- Matthew Miller Fedora Project Leader ___ 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 13, 2023 at 12:25:48PM -0400, Przemek Klosowski via devel wrote: > One missing piece might be for Fedora organization to commit to a > policy of protecting such data collections, by publishing a legally > sound declaration about its intentions and practices. Currently, we > have this > > https://docs.fedoraproject.org/en-US/legal/privacy/ > > which in my 'not-a-lawyer' view seems to be targeted to the web > collection and may be US-centric, so maybe it could use some legal > wordsmithing. Should this proposal be accepted, there will be a separate document. And, unrelatedly, the existing privacy statement is in the process of an update -- needs a refresh for legal changes, and there are number of things that it suggests we might do that I think we have no interest in and should drop (like asking for geo coordinates). -- Matthew Miller Fedora Project Leader ___ 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: What is Fedora?
On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote: > In the specific case of RHEL srpms, it makes life harder for EPEL > packagers because you can't look at the source easily when they are > problems between RHEL and EPEL packages. It matches well with RH's > standard of shipping libraries without headers etc - it is easier for them > and limits the scope of support contracts but makes upstream's life > harder. EPEL packagers should have easy access to RHEL through the no-cost subscription program. Or, reasonably easy -- I'm aware that the developer portal hoops are more... hoopy... than would be idea. But once set up, it shouldn't be difficult. If you _are_ finding rough spots in that, I can raise the issues and see if we can make things beter. -- Matthew Miller Fedora Project Leader ___ 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
CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
>> ELN is a build of (some) Fedora packages with EL-specific options, so >> it requires Fedora. > ELN can exist off an internal non fedora tree. Just depends who is > updating the tree. Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was: 1. Some Fedora Linux Release -> an internal bootstrap 2. ... a year or so of secret work ... 3. RHEL Beta 4. RHEL Release 5. CentOS Linux rebuild 6. Internal RHEL build process, internal work on minor release 7. RHEL updates appear in publiuc 8. CentOS Linux rebuilds of those. There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency. Now, CentOS Stream brings that to the surface: 1. Fedora Rawhide continually updated 2. ELN maintained in parallel, as part of Fedora 3. At some point, ELN branched to new CentOS Stream 4. ... a year or so of CentOS Stream development in public ... 5. RHEL Beta forked from that, released 6. Work on RHEL updates visible in CentOS Stream 7. Updates appear in CentOS Stream 8. Updates released to RHEL Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors. All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this: Fedora Linux: Community Space - * Community engineering decisions * No special code privileges due to your employer * Community-run infrastructure with RH investment, significant resources from Amazon, contributions from other companies * Community quality engineering with RH investment * Community support * No cost CentOS Stream: Shared Space --- * Red Hat Engineering decisions with community input * Pull requests from the community, approval from Red Hat engineers * Red Hat-provided and maintained infrastructure * Red Hat quality engineering with partner and community involvement * Community support * no cost Red Hat Enterprise Linux: Product Space --- * Red Hat Engineering decisions with customer input * Red Hat engineers and only RH engineers do the work * Red Hat infrastructure * Red Hat quality engineering (mostly done in Stream, though) * Enterprise support * Subscription, including low- and no-cost options Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.) -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Mon, Jun 12, 2023 at 09:46:26AM -0700, Kevin Fenzi wrote: > I don't think there's a formal change filed yet. > > Matthew: Did you want to do that? Or would you like me or someone else > to do so? I would love someone else to do so, but if no one else wants to, I can. :) -- Matthew Miller Fedora Project Leader ___ 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: LibreOffice packages
On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote: > However, it surprises me that for a package, that is part of the > deliverables of Fedora releases, no coordination effort was made to > transition the package from Red Hat maintenance to Fedora > maintenance. I would even go as far as that this should have been I think this sentiment is getting ahead of things. This thread _is_ that effort. Asking people to submit a Change when they want or need to stop working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.) -- Matthew Miller Fedora Project Leader ___ 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: Deprecation of the aspell package
On Fri, May 26, 2023 at 02:30:09PM +0200, Lukas Javorsky wrote: > This package has a dead upstream and has been obsoleted (in most > occurrences) by the hunspell package [2]. Oh no! I will have to update my joerc! And remember how to update my joerc! Thanks for the notice! -- Matthew Miller Fedora Project Leader ___ 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: disabling Haskell i686 packages
On Thu, May 18, 2023 at 01:12:00PM +0200, Florian Weimer wrote: > I think this will make quite a few packages FTBFS on i686 because they > require pandoc at build time. It's not that many—I count ~75 that Is there any reason to build docs for i686 packages? (With or without some cleverness that also removes doc-build dependencies without package changes?) -- Matthew Miller Fedora Project Leader ___ 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 Change Proposal: Flatpaks without Modules (System-Wide Change)
On Fri, May 12, 2023 at 09:04:40PM -0400, Owen Taylor wrote: > > So, why having all those "Fedora Containers" releases in Bodhi which > > follow Fedora branches? Isn't just one Fedora Containers release enough? [...] > The "F38 Flatpaks" release in Bodhi represents Flatpaks built with the F38 > package set against the F8 runtime. But, yes, as you say we handle Flatpaks > as a single stream. Once we release Firefox into "F39 Flatpaks", everybody > on all releases gets that and we never do an update in "F38 Flatpaks" again. > > If updates *do* get pushed on multiple releases, last pushed wins. Might be > useful if we found that we pushed something to early or broken - but isn't > normal. > > But what if we had a single release instead? A few years ago, a design team contributor was working on an animated video extolling our painless upgrade process. But, in the midst of that, they updated to a new Fedora release, and discovered that Inkscape had dropped an obscure export format which they happened to rely on. I'd love it if we could produce both "fast" and "slow" streams. Ideally that's orthogonal to Fedora runtime release, but practically speaking that's what we have now. Maybe in the future we could build a "slow" stream as part of EPEL on a UBI or CentOS Stream runtime? -- Matthew Miller Fedora Project Leader ___ 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 Change Proposal: Flatpaks without Modules (System-Wide Change)
On Fri, May 12, 2023 at 07:33:56PM +0200, Florian Weimer wrote: > I'm concerned that this is just like Software Collections with a > different path, which I believe where previously banned in Fedora (and > are generally a huge hassle on the releng side, I think). The main sticking point with Software Collections was the complixity it introduced into spec files -- lots of special macros that had to be used just-so. (And of course there were a lot of disagreements about naming things.) -- Matthew Miller Fedora Project Leader ___ 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: Place to write something up
On Thu, May 04, 2023 at 02:39:01PM +0200, Peter Boy wrote: > > The wiki might be another place: > > https://fedoraproject.org/wiki/Fedora_Project_Wiki > > Not really. Fedora decided some time ago to migrate all documentation from > wiki to Antorra CMS pages. This is not uncontroversial and everyone may > find it good or not. But that's where we are at any rate. Robyn Bergeron¹ said: "Wiki is 'where information kills itself'". Wikis _can_ be amazing platforms, but making them so requires discipline and dedicated curation. It works best when the wiki itself _is_ the project. Think of all of the obsessively-updated-and-complete wikis dedicatd to various computer games. Or TV Tropes². The Arch wiki is like this, too: in some ways, the wiki IS Arch. Ours was never like that, and grew in many different directions and gets used for over a dozen completely different things. This means it's really hard to find anything, hard to know if something is up to date or still relevant, and — perhaps most crucially — a reader is always one click away from something that will be misleading, confusing, obsolete, or just plain wrong. New docs site isn't perfect, but it is, at least, _docs_. 1. My predecessor as FPL, for the new folks around here. 2. Standard warning: Do not visit TV Tropes if you value the next 10 hours of your life. :) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Thu, Apr 27, 2023 at 12:49:02AM +0200, Kevin Kofler via devel wrote: > Matthew Miller wrote: > > I've written this: > > https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 > > and I'd love feedback on it. > > Asking feedback from users who are not using Discourse… on Discourse (!) is > absurd and the best way to not get any answers. (It is like asking "Everyone > who does not speak English, please raise your hand!" in English.) I'm sorry, I guess my phrasing was not clear. I would like feedback _about_ it. That feedback can be here or directly emailed to me. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Wed, Apr 26, 2023 at 10:20:11AM -0500, Chris Adams wrote: > So... this brings up something about this whole thread that I've avoided > but think does matter: I understand that you are the Fedora Project > Leader, but it seems like a lot of this is being done based on your > personal decisions. I believe that you are doing what you think is best > for the project (NOT questioning your motives, experience, etc.), but is > all of this entirely in scope for the project leader to decide on their > own? I think there's two mixed things here. For the forum itself, I've been acting as admin, and I admit I'm excited about it. But I haven't been making most decisions alone — I usually post in the public Site Help & Feedback forum for discussion first. (See these topics for some big examples: https://discussion.fedoraproject.org/t/considering-a-general-reorganization-of-this-site/34174 https://discussion.fedoraproject.org/t/considering-a-merge-of-ask-fedora-into-discussion-fedoraproject-org/68177) ) But in the future, and probably not the very far future, we should have a formal team around this. Second, there's the decision about what to do with devel list, or mailing lists overall. As outlined in the first post, I'm not making that decision alone. We've dicussed it in the Fedora Council, and we're having this discussion here, and the first step is the intended experiment with the Change process -- which is a FESCo decision. > You believe that the lists are outdated/blocking new contributors, but > where is the evidence to support that (and that a web forum will be > better), and who else agreed to such a change? You turned off mailing > list mode because you believe it isn't good, but who else had input? I feel like this is actually an example of the problem with so-called "mailing list mode". Out of context, that sounds like I have disabled a mode that makes Discourse behave more like a mailing list. (I mean, right?) But that's not what it does, as I've noted several places already here. So when upstream disabled the setting by default (https://meta.discourse.org/t/2-7-0-beta5-improved-invites-auto-tag-and-auto-replace-watched-words-pm-bulk-operations-and-more/182096) it made sense to me to me to just follow that change. > I'm just a little concerned that because you don't like mailing lists, > Fedora must migrate away, and to something where you'll be making more > individual decisions. Honestly, it's just plain not sustainable for me to keep doing that, whether or not it's good or bad. :) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Wed, Apr 26, 2023 at 04:34:22AM +0200, Kevin Kofler via devel wrote: > And in particular, NNTP is not supported at all, and the way the e-mail > notifications work does not lend itself to NNTP gatewaying over Gmane. Well, email (and Mailman3 and Hyperkitty and Postorious) do not support NNTP. Gmane is a software that specifically exists to bridge email to NNTP. I actually love the idea of a Discourse-to-NNTP bridge. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 12:38:46PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > In some instances at least, you can select the text in the fragment you > > are replying to, and a quote button will appear. I at least found that > > quite discoverable. > > You have to use your mouse to do it, which is too disrupting for me. There are keybindings! Use j/k to scroll up and down (ah, vi, your legacy will live forever) and q to start a reply to that post with the selected post marked as q quote, and then trim in the editor. If you have your browser's arrow-key control feature turned on (F7 in Firefox), you can use this in combination — j/k to move between posts, and then arrow keys over to shift-arrow select the part you want, and then again q to quote (or if it is a post you have permission to edit — your own, or a wiki post, or you're a mod — e to edit). -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 10:49:03AM +0200, Florian Weimer wrote: > Have you considered outsourcing email (list) operations instead? We looked into a hosted Pony Mail a while ago. But (leaving aside "I don't think that solves everything I want to address"), hosted solutions are difficult because if Red Hat is paying for it, there is an enterprise-contract process to go through, and generally a lot of vendor scrutiny and demands -- much of which is good and some of which I feel is overkill. It took over a year each to get Element (Matrix) and CDCK (the Discourse company) through the process -- and those companies had already dealt with enterprise contracts. I think it's unlikely we'll find a good open source option. > Discourse needs to solve the same issues to keep email notifications > working. Do we know how well they are doing? Discourse seems to have > stopped offering mailing list mode in the Fedora instance. I wonder > whether this is related. They're ahead of us, I think. I was recently talking to them about the possibility of using @fedoraproject.org sender / inbound addresses, and got an overview of their infrastructure and it's enough that it made me bookmark the whole thing for when I have more time. :) I turned off the mailing list mode on purpose. There's a subthread somewhere here about it. I feel like it's a trap -- it does not really enable anything special, but instead is "subscribe to ALL LISTS". That's not the best option for most people -- even people who are looking for mailing-list behavior. (It might made sense for smaller forums where the entire forum is the equivalent of one list.) If there's enough demand, we can put it back. As mentioned in the other subthread, if so I'll probably rename publicly-facing option to something more descriptive. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 04:28:16PM +, Zbigniew Jędrzejewski-Szmek wrote: > Could we have the same graph for discourse (and Fedora telegram and Fedora > matrix)? It'd be interesting to see what percentage of active communicating > users are active on the mailing list. I'm not sure how to get it from Matrix. We can get it from Discourse with some SQL queries. https://discourse.org/plugins/data-explorer.html Once we have such a query defined, I can make it available for anyone (or certain groups of people) to run. (It's not generally available because you can query _a lot_.) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sun, Apr 23, 2023 at 06:11:45PM +, Randy Barlow via devel wrote: > On 4/21/23 14:05, Matthew Miller wrote: > >Accessiblity is important to Fedora, and I take this seriously. For > >Discourse, hit the ? key to bring up the page describing keyboard shortcuts. > > One thing I don't care for when it comes to web apps and keyboard > shortcuts is that they are non-standard. When I can process > communications in my mail client, all mail uses the same keyboard > shortcuts, no matter which site it came from. With web apps, every > web app has it's own keyboard shortcuts, which makes learning them > all difficult. Yeah, that can be frustrating. But in this case at least, at least it'll be the same keys across various Discourse sites, and as noted it's pretty clearly emerging as the most common tool for open source discussion forums. I promise not to re-configure the keybindings for our site. :) -- Matthew Miller Fedora Project Leader ___ 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: Increase vm.max_map_count value (System-Wide Change proposal)
On Wed, Apr 26, 2023 at 07:42:44AM -0500, Michael Catanzaro wrote: > On Wed, Apr 26 2023 at 08:50:51 AM +0200, Vitaly Zaitsev via devel > wrote: > >If needed by Steam or Wine, they should provide a .conf file instead > >rather than changing this setting system wide. > Problem is this doesn't work for containers Also, is that a global change? Generally we _shouldn't_ drop in overall system configuration via individual packages. It leads to surprising results and is hard to diagnose. (Oh! You are getting the OOM killer because you happen to have steam installed, even though it's not running...) -- Matthew Miller Fedora Project Leader ___ 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: A new FMN will arrive this week
On Wed, Apr 26, 2023 at 10:42:36AM -, Aurelien Bompard wrote: > Yes, Badges has still not been ported over to Fedora Messaging. It's > actually the last remaining piece I think, with FMN done. Until then, FMN > can't understand the messages that Badges emits, so you can't subscribe to > notifications yet. Sorry about that! Badges is on our list of tech debt to > handle, so hopefully it won't last too long. s/tech debt/older software that needs work to reduce ongoing maintenance costs/ :) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 03:33:28PM -0400, Solomon Peachy via devel wrote: > Honestly, if a "how to configure discourse to mimic the MUA-managed > mailing list experience (ie not having to log into a web site after the > initial configuration)" document is produced, that's probaby sufficient > to overcome most of these objections, because then the setup cost is > one-off, and the ongoing "interact with Fedora-devel" cost won't be any > greater than it already is. (It's not the setup cost that's a problem, > it's the per-transaction/interaction cost, which is currently _higher_) I've written this: https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 and I'd love feedback on it. Keep in mind: * It never will be the same as mailman. There are different constraints. * Discourse developers and designers see the web interaction as primary, and that isn't going to change. * Dealing with email has a lot of corner cases, so there will be rough edges. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 02:00:02PM +0200, Kamil Paral wrote: > This is a part I agree with. I've been very annoyed by the gamified > achievements, and I haven't found a way to completely shut them off. > Fortunately they stopped appearing after some time, perhaps I earned all of > them already. Or perhaps they were enabled on Ask, but they're not enabled > on Discussions? > > Matt, is this something configurable? Yes, I turned them all off on Discussion. (Except the one for having 10+ accepted answers in Ask.) My intention (in very hacky prototype currently) is to replace those all with Fedora Badges. These will only appear for people who have enabled that (although we may want it to default to on eventually, once Badges is in better shape). And while I hope to have some for Discourse participation, those will be part of the overall Fedora Project ones. (Including replacing the 10+ answers one.) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Tue, Apr 25, 2023 at 07:00:20PM +0200, Fabio Valentini wrote: > - Change Proposals could be *announced* on the devel list, but > discussion could happen in a linked topic on Discourse This is basically my proposal, although I suggest devel-announce rather than devel-list, because otherwise the result is two separate discussions. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 04:05:41PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > And this includes both mentoring them to be able to contribute, but also > > accepting the fact that new people can bring new ideas, and we should > > provide them space to work on them and not just expect them to follow and > > do what they were told to do. > > [^^ side note about the above ^^^ > Your mail client breaks quoting: it only inserts ">" on the first > line, and not the later lines of the quote. This makes your mails > harder to read than they should be. The same is true in your other > mails, it's not a one-off thing.] This is probably Gmail's web client. It does this, and other odd things that make it very frustrating to use for anything but "top-post, quote-everything". -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 03:04:26PM -0700, Kevin Fenzi wrote: > I have been pondering if we could perhaps setup a public-inbox read-only > mirror of the posts to discussion. ( > https://public-inbox.org/README.html ). It would take a bit of work, as > I think we would need to make a non priv user, subscribe to everything, > then mangle the emails as they come to not have the reply-to or anything > else thats specific to the user. However, that could be a solution to > longer term archiving of things, another way for casual people to read > things and also allow a nntp frontend for the crazy nntp folks. ;) > public-inbox is plain text only, so no images/html there. > If there's enough interest in this I would be happy to work with folks > who want to set this up. Rather than email subscription, this could be via a webhook. That payload includes both the html and "uncooked" message, a bunch of metadata. And it can trigger on post, edit, metadata change, and other things. That's probably a better interface than email mangling. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sun, Apr 23, 2023 at 05:23:34PM +, Mattia Verga via devel wrote: > - I'm also skeptical about having all mailing lists under one Discourse > category (I suppose it will be "Project Discussions") and use tags to > filter them. I think an high volume list such as devel should gone under > it's own category. Maybe for other low volumes lists which are specific > to groups or aspects can use the "tags" categorization. I think the several different functions of the list belong in different tags. What's here and what's on some other list (or already on a different platform altogether) is largely an accident of history. If it does seem like there's a clear set of things which could be split to a different category, we have that option in the future. The category of a topic is just metadata, so chagning it is fast and doesn't change URLs or anything. > - Another problem is that there are already too many tags available and > the tag description is not visible in the post submit form. I think a > new user would be confused what tag to use. I'm confused too, but that's > probably just me... That's useful feedback. We're working on making that better. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 05:40:41PM +, Zbigniew Jędrzejewski-Szmek wrote: > I think this is a great place to start. If it works, wonderful. If it > doesn't work, then we can delay/abort/redesign any later steps. Exactly. > > > Second, I think other FESCo-related conversations should move. I hope > > this will reduce the urge to have back-and-forth exchanges in the > > tickets. For the Fedora Council, I set up a bot which automatically > > creates a discussion topic when a ticket is filed, leaving the ticket > > just for votes and recording of outcome. FESCo could use something > > similar. > > Could we instead have a poll which is open only to members in a FAS > group and tally those votes? I guess this would be useful for other > things too. (E.g. as a replacement for blocker-review [1]). Yes, that's possible. (The group sync stuff is almost in place -- infra SOP docs getting finalized.) > [1] https://pagure.io/fedora-qa/blocker-review > > And finally… shut down the devel list itself. Perhaps at the end of > > 2023? > That seems way too early. Let's not plan for this until it is clear > that we can do that without losing contributors. Fair enough! I intend to only submit the Changes move to FESCo at this time (or, once this discussion has settled), and the rest can come as it does. I just wanted to also give a clear picture of what I'm aiming for right up front. -- Matthew Miller Fedora Project Leader ___ 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: Increase vm.max_map_count value (System-Wide Change proposal)
On Mon, Apr 24, 2023 at 05:07:53PM -0400, JT wrote: > How this would affect memory performance on a workstation or server with > much more running concurrently, is something I can't really speak to, but I > would guess there's a point where increasing it could cause issues > depending on total memory available and how many processes are getting > memory reservations from the kernel. For what it's worth, our friends over at SUSE have a kbase article on the possible side-effects of increasing this setting. Find it at https://www.suse.com/support/kb/doc/?id=16692. (In short, the consequences are that processes which map more memory can do so, which is bad for memory usage overall and can hurt performance.) -- Matthew Miller Fedora Project Leader ___ 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: Firecracker microVM manager
On Sat, Apr 22, 2023 at 10:13:31AM -0400, David Michael wrote: > > Would it be possible to add a warning to this effect? Without any form > > of sandboxing Firecracker is not suitable for production use. > Where would such a warning be placed? The sandboxing is done by a > standalone program[0] which is not built in the package, so it should > be clear that it isn't available. Silly question: would it make any sense at all to use _podman_ as a replacement for firecracker's jailer? -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Sat, Apr 22, 2023 at 07:01:06AM +0300, Benson Muite wrote: > > https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/3 > This is helpful. Wish it were a magazine article. Those get read. Interesting idea! I'll check with the Magazine team to see if they think it would be a good fit. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 08:53:26PM +0200, Miro Hrončok wrote: > 1. Python discussions are no longer at the same place as all the > other discussions (my Thunderbird). This is a big one for me. I > cannot primarily use the Discourse web interface on > discuss.python.org because I simply won't go there. I suppose that I mentioned somewhere else around here that I use the Android "Discourse Hub" app as a way to keep up with this — I see notifications from Python, Home Asssitant, Flatpak, etc., even though I don't visit those sites daily. I kind of miss this on the desktop. I wonder if a web app that does the same thing would help you too? As more and more projects use Discourse, that could become a sort of nexus for all of these gardens that Jonathan Corbet mentions. > > 2. When I read the content in the web app, it does not mark the > related emails read. I can either read everything via email (which > frankly has a worse readability than the web app) or go read it on > web and than manually mark my emails as read. So far, this has been > tedious for me so far and I repeatedly give up and mark the entire > Python Discourse folder as read when the number reaches 10k unread > emails. Even if I read everything via email, I cannot reply there so > I still need to visit the thing in the web app to participate. We have reply-by-email enabled. It is also possible to enable new topics by email, but that's vulernable to impersonation (and spam) so if we enable that there probably will be a moderation step. > 3. When I choose to use the mailing list approach, I can no longer > distinguish "regular" email notifications (somebody replied to my > comment or mentioned me) from the rest of the email traffic from the > forum. This will apply to others as well; e.g. when I send an email > to devel now, I can CC people I know need to see it -- on Discourse > I can mention them, but they might not notice that if they receive > an email of everything anyway. Can you use the Feedback-ID header to distinguish and highlight those personal notifications? > So far, when Python switched from mailing list to Discourse I've noticed this: > > Once I participate in a certain discussion, it somewhat works, as > long as I remember to go check it out occasionally. But OTOH I miss > out almost everything I don't actively participate in. > > --- > > Perhaps I am a greybeard, but I am pretty much scared of this change in > Fedora. > > > You say we miss people now. I say we will miss them then. > Unfortunately, I don't know how to solve that. Maybe my fear is not > justified, but it is real. Thank you. I appreciate the real-world feedback from the Python experience. What about, instead of mailing list mode, enabling the Activity Summary email, and setting it to daily instead of weekly? That gives a reminder (and hopefully something interesting) but keeps the web site as primary for actual notifications and for keeping track of what's read and not read. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 07:05:05PM +0100, Tom Hughes via devel wrote: > >"Mailing list mode" was a specific thing in earlier versions of Discourse — > >it sent a notification for every message posted. This is kind of like going > It's still a thing in current versions, it just doesn't seem to be > available in the Fedora installation. It's hidden from the settings UI by default in new installs. Looks like it is still there as an option to enable, but I really do think it's kind of a trap. If the category watch thing doesn't work for you (and others) for some reason, I can re-consider. If so, I might rename it to "email me everything that isn't muted" instead of "mailing list mode", though > It also doesn't have to send you everything as you can mute those > things you don't want to include. That will at least keep you from getting thousands of Copr posts. :) > Having to positively opt in to certain tags seems like a terrible > idea as you're bound to miss lots of things when people create new > tags that you don't even know exist. I'd much rather get everything > by default and then opt out of the things I'm not interested in. In that case, subscribing by category should do the trick. Categories are not light-weight, so we're unlikely to create new ones without fanfare. It's not just one checkbox, but there are only a handful of main ones anyway. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 11:54:09AM -0400, JT wrote: > So I'm interested by what you bring up here. Have you run into situations > where someone wanted to contribute to development but was unwilling to use > a mailing list? With a community as big as Fedora and with a multitude of I talk to a lot of people about getting involved in Fedora. "Sign up for this mailing list and introduce yourself" is a big drop-out point. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 07:39:17PM +0200, Jaroslav Prokop wrote: > >>I am, luckily, not paid to read forums > >>with no threading. IMO, a stream of posts with mentions of previous > >>posts is not threading. Threading begins and ends > >>on new topic posts AFAICT on discourse. > > > >It's not presented as a tree, but there _are_ threads of replies. > > Heh, sounds like a fun side project to try to transform it into a > tree structure. If you want to make Jonathan Corbet happy, make that tree structure be then served via NNTP. :) > >Example:https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397/83?replies_to_post_number=83 > Finally, noticed what it does, it made me a bit confused as the > first response was the same as in the "global" flow of the topic, > but the message under it changed. I think that it should be better > visible that they are actually replies. > > It seems to hide other replies and only show those that are part of > the "thread". Do they accept RFEs? :) They do -- post at https://meta.discourse.org/. > I think enhancing the visibility after I expand replies for the > posts in the "thread" would be better. This particular thing could possibly be done via a theme component (see https://meta.discourse.org/t/about-the-theme-component-category/232731), which is a kind of lightweight plugin for the client-side. (These are very easy to install into a given site, unlike weightier server-side plugins.) Or maybe even just some CSS. What exactly did you have in mind? -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 11:37:20AM -0400, Simo Sorce wrote: > So I registered the account, added the email I want to get > notifications at, and selected a few topics. > > First impressions. > > It is absolutely confusing to figure out how to watch topics. > If you select a category and a topic you do not get the notification > bell to watch them. > If you select just a topic you get it. > Topics are all in random order. When you select some topic by searching > you sometimes are then proposed a different one (? renames ?) A terminology thing: I think what you are calling "topics" discourse calls "tags". Each discussion or thread is what discourse calls a "topic". Watches are by category, by tag, or by individual topic. > > I found no way to watch all, and let my client sort it out ... which > would need client filtering, because the stupid gmail filtering can't > handle header fields (#@#%$@#). Watching at the category level is probably the closest thing here. That is, watch Project Discussion and News & Announcements at least. That will include all topics under those categories regardless of tag. As for Gmail, see https://gist.github.com/tpopela/e2f17bf8eac15bee734b993e170f4dfa. I'm trying to get Tomas to write a Discourse post about that. > They come several minutes (at least 5 minutes, as the email is *sent* > that much later, and the sent date is set to when the email is sent, > not to when the post is made) after the actual message is posted in > discourse, I do not care much, I generally read asynchronously as well, > but it is sometimes annoying not to be able to establish the real time > a post was made. Oh that's interesting. I'll bring that up. The five minute delay is actually a site-wide configuration option: it gives time for the poster to make any quick typo fixes, add tags they forgot, etc. before the mail is sent. (The default is 10.) > The only way to know who posted is by looking at the From field, where > the description of the notification email address is changed to include > the display name of the poster. That is a bit confusing at times. > > There is no formatting in the mail that tells me who is someone > replying to, or which message in the thread it was being replied to (I > disabled sending me the whole thread with each notification, I may re- > enable it). Do you have "Include an excerpt of replied to post in emails" checked? Does that help? > The test part so far is otherwise decently rendered, and for image > posts it is clear enough that there is something to look at in the html > part. *however* the images are not embedded in the email, so all that > information is unavailable offline or for archival (and in my > configuration requires to actively pull images as I configured my > client to not pull 3rd party content automatically for privacy and > security reasons). Reasonably enough. There might be an option to embed images -- I'll look. For what it's worth, the images should all (and only) come from the dedicated CDN site for our hosting, and there's no linked tracking on our side or Discourse's. There's probably logs somewhere, though. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 11:02:15AM -0500, Chris Adams wrote: > I really can't imagine a change for me (and I apologize if that sounds > really "grumpy old man"... which I guess it starting to apply to me, > since I was in college when a friend told me about some guy in Finland > saying "hey Minix people..."). It really comes down to how I use a > computer I guess; I am highly keyboard-focused, and I haven't seen a web > forum yet that can handle that. Some have a few keyboard shortcuts, but > they rarely fill the whole use and often are not well-maintained. Accessiblity is important to Fedora, and I take this seriously. For Discourse, hit the ? key to bring up the page describing keyboard shortcuts. If you find something you can't do, I'll report it as a priority bug. > Email lets me have full control of how I consume it. I can sort it my > way, save what I want and delete the rest, flag things for more review, > etc. Web forums force me to consume their content their way, and then > when I maybe have a way to deal with it, they change things. Also, I > can easily edit email posts in vi until I get my message the way I want > (for example, this paragraph started out as a sentence further down the > message :) ). It's true that the composer is a web thing rather than your own editor (although there's browser plugins for that...). And it's also true that the software changes and not necessarily on your timeline. But with that in mind: * Discourse does let you compose and save draft messages * There's a handy "bookmark" feature which I use all the time. You can give a reason for bookmarking something so you remember later, and give it a future time to notify you. > I tried loading https://discussion.fedoraproject.org/ in Lynx, but it's > way too "busy" to be able to visually browse it, and of course it has > the "best viewed with JavaScript enabled" tag, which is usually > kiss-of-death for Lynx users (in fact, I couldn't see a way to log in or > post/comment). I'm actually pretty impressed with how decent it is in elinks for a modern website. I do think you need Javascript to post, though. (And our elinks does not seem to be built with such support, which probably isn't sufficient anyway, alas.) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 08:24:14AM +0300, Benson Muite wrote: > However, it doesn't seem like we can hack on it to better suite > community needs, for example to have the same functionality as mailing > lists[2]. It is not standards driven and is primarily developed by one > company - something that follows Apache way[3] or has a community > governance process would be better in the long term for a large project > with many contributors who have technical expertise. We definitely _can_ hack on it to better fit community needs. Changes might not automatically get accepted, but we've got a good relationship and I don't expect any kind of antagonism if we have something important. On 2) https://discourse.cmake.org/t/cmake-discourse-mailing-list-mode-incorrectly-personally-addresses-all-email/738 in particular... that's just the Cmake forum admin saying that the particular thing doesn't exist, not a Discourse dev saying they won't take a change. Although on that specific change Discourse attaches List-Id and other standard email headers (as well as some specific X-Discourse headers) to each message. Changing the To: line to be some list address could be done with a plugin, but might actually have negative consequences for reliable delivery. > Email clients offer significant customizability that a one size fits all > web interface cannot provide. Mailing list mode for Discourse is > helpful, but not at the same level as email lists, where once one has "Mailing list mode" was a specific thing in earlier versions of Discourse — it sent a notification for every message posted. This is kind of like going to Hyperkitty and saying "subscribe me to all 600 lists". I don't recommend that. Instead, choose specific tags that you want to subscribe to, just as you would subscribe to individual mailing lists. I have a post about this and Fedora Discussion specifically: https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/3 -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 11:07:16AM -0500, Chris Adams wrote: > Once upon a time, Matthew Miller said: > > * also, to fix typos :) > > So, I will say this is kind of a peeve of mine about server-based > discussion systems (whether web or client like Slack/Discord): allowing > people to edit messages, especially after people have replied to them, > is a bad idea. Person 1 says "we should do XYZ", somebody replies "no > XYZ is bad", and person 1 can go change their original message to say > something completely different. Do you mean maliciously? In that case, it's a matter of asking people to not do that. Or do you mean that it makes the history of the conversation confusing? The history _is_ there — edited posts are marked as such and you can see the changes. I think in many cases it's fine for edited posts to reflect an updated understanding. If I post something and later realize I was confused, and so fix it, in a year no one will care about the initial mistake and it's more useful to have a "clean" post. (And any replies telling me I was wrong can be deleted, having served their purpose.) Of course, that kind of "timeline edit" isn't appropriate for something that's a big decision or where the hashing-it-out _matters_. But it's very useful for posts like https://discussion.fedoraproject.org/t/fedora-strategy-2028-a-topic-index-for-our-planning-process/46733 -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 10:47:24AM -0400, JT wrote: > While there definitely was an increase in interaction with people, that > also came at a cost. Two or three devs having a conversation in a thread > would also have to deal with a dozen or so no- devs chiming in on the > situation and putting in their two cents. Time and again this would end up > being nothing more than a distraction, an argument, or causing a developer > to end up going to PMs to discuss the bug they were trying to resolve > instead of doing it openly. I don't want to do this prematurely, but we do have some options for handling this. We are (very soon now) going to have sync of FAS groups to Discourse. If we want or need to, we could limit posting in Project Discussion to people who are members of one or more FAS groups. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 04:14:33PM +0200, Peter Boy wrote: > You put it very nicely. I have been desperately trying to follow new posts > under the tag #server via email notification. Total failure. I missed > everything. What could have made that go better? > A nice collection of "bells and whistles" just doesn't cut it yet. > Currently, it is far too unreliable for systematic and long-term > professional activities. > > And it is structured in an undercomplex way. Try to find something further > back in time. You must have a lot of boredom. A simple grouping by > year/month like the mailing lists is very comfortable in comparison. There isn't (as far as I know) a browsable year/month view, but you can limit searches with before and after: https://discussion.fedoraproject.org/search?q=%23server-wg%20after%3A2021-01-01%20before%3A2021-02-01 -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 10:31:04AM +0300, Panu Matilainen wrote: > I actually quite like Discourse - for a forum software - from > experience related to various freetime activities. > > However, Discourse replacing mailing lists WILL be the end of > habitually skimming through everything that goes on devel (and a > whole bunch of other lists) to spot issues that might be of my > concern. The result will be in me being considerably less aware of > what goes around in Fedora, rpm related or not. You can get notifications of every post in tags you want to follow by email, and presumably skim them in the same way. Maybe there's something we could do to make that better for you -- can you help me understand what doesn't work well? We have another feature which might be of interest: we have enabled the "saved searches" plugin. You provide search queries, and whenever there is a new patch, you get a notification. (You can decide if you want these immediately, hourly, daily, or weekly.) https://discussion.fedoraproject.org/t/new-site-feature-saved-searches-get-notifications-if-a-new-post-matches/46892 -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 09:38:26AM +0300, Alexander Bokovoy wrote: > My main trouble with Discourse and other places where I try to help > people with answers to their questions is that forums promote a drive-by > questions without further engagement. This experience is opposite to > what forum proponents are claiming but I see it pretty consistently on > Discourse, on Stackoverflow sites, on Reddit and in many other places. I think some of that is natural in any support forum. The same thing happens on the Fedora Users' mailing list. > In my area, identity management and authentication, the topics are > complex enough to want to help others but lack of further engagement > simply kills any interest to use a particular discussion board. If > people asking questions aren't interested in getting the answers or even > tying in the ends for their own questions, it comes hard to keep an > interest in helping those people again and again. > > I can point you to one specific topic on Fedora Discourse as an example: > https://discussion.fedoraproject.org/t/fedora-login-bug-having-a-128-character-password-breaks-otp-and-will-lock-users-out-of-account/78960 Well, in that case, I think the person was primarily interested in getting access to their account back, not the underlying bug. Justin helped them find where to file a ticket, and presumably everything was resolved from their point of view. > I would have supposed that someone would follow-up, right? As a > FreeIPA maintainer in Fedora, as an upstream FreeIPA contributor and a > contact for security issues, I have never been contacted with either > details for what the thread claims to happen or never got any follow-up > on the thread to my comments. I really don't think that's a _tooling_ issue. > > This is an experience I want to avoid. If this is what Matthew is > proposing a Fedora development discussions to be, then sorry, this is > not an improvement. Well, no. It is not what I am proposing. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 08:45:31AM -0600, Jonathan Corbet wrote: > I will just make the point that, when you make this switch, you will be > missing people as well. Projects that switch to forum systems, to a > great extend, go dark for people who aren't immersed in them all the > time. Keeping up with fedora-devel takes very little of my time; > keeping up with Discourse instances is a much slower affair. What could we do to make that easier for you? -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 08:27:06AM -0400, Robert Marcano via devel wrote: > I forgot to add. Discourse is worse for mobile users, the "app" was > just an embedded web browser, the only thing efficient it did was to > get a notification and remembering your session, everything else is > worse that writing an email on a email client for phones. For what it's worth, I use Discourse on my phone all the time. As you say, the app is just a thin wrapper around the mobile web UI, but I like that UI well enough. And the wrapper is nice as a "hub" for various discourse sites, where I can see all of the notifications in one place. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
side filtering unparalleled by any platform that I used in the > past. It's fine, but it's no NNTP. That was really the best. :) Do take a look at https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 It's not perfect, but it's better than most other forum software's email interfaces. > I enjoyed Fedora being on mailing lists, nothing ever came close to the > threading of emails. I was not getting lost in threads of conversation > while still being under the umbrella topic, no need to open who knows how > many links to read all tangents. I appreciate your perspective, feedback, and willingness to try this out! -- Matthew Miller Fedora Project Leader ___ 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
tangent on tag curation [was Re: It’s time to transform the Fedora devel list into something new]
On Thu, Apr 20, 2023 at 06:01:51PM -0700, Adam Williamson wrote: > Well, I just opened the tags box and typed 'qa', and got...#fedora-qa , > #qa, and #qa-team . So it looks like some maintenance might be in > order. :D Is there any way to 'guide' people to use 'standard' tags? Ah, see, this is a great example of a tangential subthread I'm still trying to figure out the best approach to one issue with tags since we merged in Ask Fedora. Tags span across categories, including tag watches (that is, subscriptions). This means there's no way to subscribe to notifications for, e.g., #server in Project Discussion and _not_ to those in Ask. Ask can be kind of firehose of end-user queries, I want to make sure we have that option. So, there is #server-wg (which we're probably going to rename to #server-devel to be less obtuse) for that. These "team" tags can only be used in the Project Discussion category (and Announcements). For qa, that's #qa-team. Then, there are some things that are tagged #fedora-qa in Ask. "fedora-qa" is not particularly consistent, but #qa alone is kind of ambiguous and would get misused. As it was, #qa was set up as a synonym of #qa-team -- that's unnecessary and I've removed it. Overall, tags in Ask are more of a wild territory. We discussed and have some general consensus on how they should be used: https://discussion.fedoraproject.org/t/how-should-we-use-tags-in-the-ask-fedora-category/45221 and I do a kind of lackadaisical periodic curation. (Tags can be created by anyone with a certain forum trust level, which scales with participation. But they can only be edited and removed by admins.) (Although actually the emails triggered by notifications _do_ include `X-Discourse-Tags` and `X-Discourse-Category` headers, so if that's the your primary way of interacting, you _can_ do something with them. But it doesn't apply to on-site notifications.) -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Thu, Apr 20, 2023 at 08:24:48PM -0500, Chris Adams wrote: > Once upon a time, Matthew Miller said: > > I am proposing that over the course of 2023, starting with the Changes > > process, we move Fedora development conversations from this mailing list to > > the Discourse-based Fedora Discussion. > > I feel this is a case of trading one group of people (email list users) > for a different group of people (web forum users). I don't think this is _really_ a "there are two kinds of people in the world..." situation. Of course there are some people who have preferences (strong or weak) for one or the other, and completely legitimate pros and cons to each. But I don't want to "trade" anyone. I'd like to bring everyone along. > I have seen this > done multiple times over the years, tried to follow a few times, and > always dropped off fairly rapidly. I'm solidly in the "email list > users" group. Is there anything which could be different this time which would make it better for you? -- Matthew Miller Fedora Project Leader ___ 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
It’s time to transform the Fedora devel list into something new
your individual email address is hidden, so it won’t be a spam magnet (or a target for off-list harassment, a problem we unfortunately have with devel list). That said, it is web-first software. (Or mobile, if that’s your thing.) That requires some adjustment, I know. I hope opening up a Fedora Discussion tab – or keeping one open — becomes an easy habit. Not just Fedora --- There’s a big trend towards Discourse in open source projects overall. Python and Gnome have both migrated entirely from their mailing lists. Ansible is working on it. Plus, there’s Rust, Kubernetes, Nextcloud, Flathub, Grafana, Home Assistant, KDE, and I’m sure many others. Concrete proposal - I’m not suggesting we shut down devel list next week. And I think we’ll have some mailing lists for quite a long time. But, I think it’s time to start moving some specific things, with the eventual goal of closing every mailing list we can. First, I’d like to move the Changes discussion. They will still be posted to devel-announce, but responses directed to Project Discussion in a new #changes tag. Ben tells me that this is a FESCo decision, which seems reasonable. Second, I think other FESCo-related conversations should move. I hope this will reduce the urge to have back-and-forth exchanges in the tickets. For the Fedora Council, I set up a bot which automatically creates a discussion topic when a ticket is filed, leaving the ticket just for votes and recording of outcome. FESCo could use something similar. Third, I’ll add a tag for general Fedora OS development conversation. Maybe “#devel”, but if someone has more narrow suggestions, I’ll take them. Fourth, I’d like to update our documentation, process, and expectations for newcomers — say hello on Discussion (and Fedora Chat, if you like) rather than a mailing list. (I’d like to close the Fedora Join list at this point.) Fifth, all packaging-related discussions (including the separate packaging mailing list). We already have a #package-maintainers tag with some existing discussion. Sixth, automated posts, as much as we can. These should go to dedicated Workflow categories, where people who want can watch them but where they won’t overwhelm human interactions. People who want can watch them, and it’s easy to quote-reply into a new linked topic in the Project Discussions category. And finally… shut down the devel list itself. Perhaps at the end of 2023? We should also shut down all of the little lists that haven’t had anything but spam in the last two years. We could maybe do that sooner. We should stop creating new lists now — we can create new Discussion tags instead. I expect the announcement lists to stay for the foreseeable future (although we might feed them from Discourse rather than the other way around). Other lists which are patches, commit messages, and other automations might stick around for a while — but really might be better served by a log aggregation and analysis system or something else. Other teams who want to keep mailing lists can, but I’d like to move those too, and eventually I think we’ll want to shut them down too — or perhaps convert them to announcement lists. Next steps -- I know this is a big change. I’ve been thinking of writing this message for a long time. I’d really like to convince everyone that it’s the right thing — or at least, an acceptable one. What about specific decisions related to my proposal? For each: Because altering the Changes process is a FESCo decision, I’ll file a ticket about that shortly. FESCo moving their own other conversations is, of course, also a FESCo decision. Assuming the first moves forward, I will create the general #devel tag (or other name we come up with) when I create the #change-proposal tag. Moving the packaging list is a Packaging Committee decision. Automated posts can be moved at any time. I can work with the people who own the generation of those reports to figure out a good answer for each. The outcome for other team lists is up to each team. And, I think shutting down devel overall is ultimately a Fedora Council decision. For right now, though: let’s discuss — on the list! -- Matthew Miller Fedora Project Leader ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, Apr 20, 2023 at 05:53:34PM -0400, JT wrote: > Sometimes, someone only cares about one subtopic. Yes I know this can be > somewhat addressed with proper tagging, but that takes constant effort by > everyone involved to make that useful. Most users wont use them, so its up > to mods or other site users to constantly be back filling that > information. It's a constant effort that must always be made to keep > things orderly. It exchanges immediate convenience for recent information > for a more long term effort to keep older information as easily accessible > as it would have been in a mailing list or a classic forum/sub-forum style > structure. For tagging, in the Project Discussion category, each topic requires at least one tag, and all of the available tags are from a relatively-short list meant to correspond directly to active project teams. You can think of each of these as a kind of mailing list — you can subscribe to or mute each of these tags. For example, you can find docs team topics at https://discussion.fedoraproject.org/tag/docs-team In my experience in the last year or so with this structure, it works well and doesn't require a lot of maintenance. The Ask Fedora category uses looser tagging generally based around topics, and c For older information, Discourse has significantly better search than Hyperkitty provides. > And speaking of older information... there's another problem with them in > that aspect... the ability to work with them offline or local copy is not > possible with a SAAS solution like discourse. That's basically true, although there is an API and it would be theoretically possible to make an offline client of some sort. We also have automatic backups so that all of the data is available in a Fedora-controlled way. > As I do a lot of historical research in open source and actively archiving > what I can for future people. This is something I focus on and while I > know there's not many of us that are doing it, it's still a thing for some > of us. Working with old Distros and trying to research how we got from > there to here has only been possible because people back in the day > archived mailing lists and things like sunsite.unc.edu I can scrape a > modern mailing lists for reference later, and pull up mailing lists that > others have archived before me. > > In an effort to be more efficient and "modern", are we taking away that > possibility for the next generation? I care about this too. I don't think we are taking away the possibility of archival research. But, also: "efficient and modern" aren't in my reasons for suggesting this. > Using a SAAS solution doesn't seem to make that possible, but maybe I'm > wrong and there is a way that I dont know about. Will there be an effort > to export a PII sanitized database for people to use as an offline or local > reference. I don't have an effort like that planned, but I would not be opposed to someone who wants to work on that. -- Matthew Miller Fedora Project Leader ___ 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: It’s time to transform the Fedora devel list into something new
On Thu, Apr 20, 2023 at 05:39:51PM -0400, Stephen Smoogen wrote: > I hate to ask this but could you give a more summarized version of this > email? I realize you had a lot of reasoning you wanted to cover on the > why's but I frankly got lost several times. That makes it really hard not > to respond in ways which are overly emotional and not helpful. Anything I > wrote would start with me trying to summarize what was written but failing > to do so, or I would end up trying to pick apart different paragraphs in > non-helpful ways. Sure. I realize it is quite long. I am proposing that over the course of 2023, starting with the Changes process, we move Fedora development conversations from this mailing list to the Discourse-based Fedora Discussion. Many Fedora folks, new and old, can't keep with this list. The number of participants is down over time (even as the number of threads has risen). Many teams are moving away from devel list anyway -- using various scattered bug trackers as their effective "forum". Discourse gives us better tools for the conversations we need to have as a project. I know it takes some getting used to, but I strongly believe it will be worth it. Devel list actually covers a lot of different topics. Discourse lets us categorize those better while still keeping it all together. The first thing I suggest moving is discussion around proposed Changes. This is a FESCo decision. The rest I won't duplicate here. -- Matthew Miller Fedora Project Leader ___ 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
It’s time to transform the Fedora devel list into something new
your individual email address is hidden, so it won’t be a spam magnet (or a target for off-list harassment, a problem we unfortunately have with devel list). That said, it is web-first software. (Or mobile, if that’s your thing.) That requires some adjustment, I know. I hope opening up a Fedora Discussion tab – or keeping one open — becomes an easy habit. Not just Fedora --- There’s a big trend towards Discourse in open source projects overall. Python and Gnome have both migrated entirely from their mailing lists. Ansible is working on it. Plus, there’s Rust, Kubernetes, Nextcloud, Flathub, Grafana, Home Assistant, KDE, and I’m sure many others. Concrete proposal - I’m not suggesting we shut down devel list next week. And I think we’ll have some mailing lists for quite a long time. But, I think it’s time to start moving some specific things, with the eventual goal of closing every mailing list we can. First, I’d like to move the Changes discussion. They will still be posted to devel-announce, but responses directed to Project Discussion in a new #changes tag. Ben tells me that this is a FESCo decision, which seems reasonable. Second, I think other FESCo-related conversations should move. I hope this will reduce the urge to have back-and-forth exchanges in the tickets. For the Fedora Council, I set up a bot which automatically creates a discussion topic when a ticket is filed, leaving the ticket just for votes and recording of outcome. FESCo could use something similar. Third, I’ll add a tag for general Fedora OS development conversation. Maybe “#devel”, but if someone has more narrow suggestions, I’ll take them. Fourth, I’d like to update our documentation, process, and expectations for newcomers — say hello on Discussion (and Fedora Chat, if you like) rather than a mailing list. (I’d like to close the Fedora Join list at this point.) Fifth, all packaging-related discussions (including the separate packaging mailing list). We already have a #package-maintainers tag with some existing discussion. Sixth, automated posts, as much as we can. These should go to dedicated Workflow categories, where people who want can watch them but where they won’t overwhelm human interactions. People who want can watch them, and it’s easy to quote-reply into a new linked topic in the Project Discussions category. And finally… shut down the devel list itself. Perhaps at the end of 2023? We should also shut down all of the little lists that haven’t had anything but spam in the last two years. We could maybe do that sooner. We should stop creating new lists now — we can create new Discussion tags instead. I expect the announcement lists to stay for the foreseeable future (although we might feed them from Discourse rather than the other way around). Other lists which are patches, commit messages, and other automations might stick around for a while — but really might be better served by a log aggregation and analysis system or something else. Other teams who want to keep mailing lists can, but I’d like to move those too, and eventually I think we’ll want to shut them down too — or perhaps convert them to announcement lists. Next steps -- I know this is a big change. I’ve been thinking of writing this message for a long time. I’d really like to convince everyone that it’s the right thing — or at least, an acceptable one. What about specific decisions related to my proposal? For each: Because altering the Changes process is a FESCo decision, I’ll file a ticket about that shortly. FESCo moving their own other conversations is, of course, also a FESCo decision. Assuming the first moves forward, I will create the general #devel tag (or other name we come up with) when I create the #change-proposal tag. Moving the packaging list is a Packaging Committee decision. Automated posts can be moved at any time. I can work with the people who own the generation of those reports to figure out a good answer for each. The outcome for other team lists is up to each team. And, I think shutting down devel overall is ultimately a Fedora Council decision. For right now, though: let’s discuss — on the list! -- Matthew Miller Fedora Project Leader ___ 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: Future of encryption in Fedora
On Thu, Apr 06, 2023 at 12:55:28PM -0500, Michael Catanzaro wrote: > There are a couple more disadvantages to using Discourse: > > * Several of the replies are lower-quality and are not contributing > to the conversation. That happens here too, of course. I think it's really a consequence of greater conversation visibility rather than Discourse per se. And, Discourse gives greater ability to moderate those -- either to hide them, or to split them out into separate discussions so they don't distract. Or, at a greater extreme if we want to do this, we could limit direct participation in some discussions to members of FAS groups we decide (others could participate by replying in linked threads). > * There is no threading like we have with emails, so these replies > are more disruptive and the discussion is less organized. There actually _is_ threading in Discourse topics. It's just not presented in as a nested tree. For example: https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397/4?replies_to_post_number=2 I probably should have been a little more active in moderating that thread. But also, I'm working on building up a bigger moderation team to help with that. (This too is waiting on the FAS group sync.) -- Matthew Miller Fedora Project Leader ___ 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: Future of encryption in Fedora
On Thu, Apr 06, 2023 at 12:56:55PM -0400, Owen Taylor wrote: > On the downside, spam limits on new posters have gotten in the way in some > cases, and people have had some trouble figuring out how to use the quoting > features, resulting in disconnected responses. I have bumped some of the default limits -- and I have a planned solution for this long-term Fedora contributors in the very near future, as we will soon have FAS groups synced to Discussion. When that is available, we can make it so membership in a FAS group automatically grants "trust level 1", which removes most limits. (The "trust level 0" limits are pretty important to stop spammers and trolls, so I don't want to relax them further.) -- Matthew Miller Fedora Project Leader ___ 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: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later
On Thu, Mar 09, 2023 at 11:41:09AM -0500, Todd Zullinger wrote: > > I am doing the conversion of license tags in my projects and i have a > > project where some files are under the GPL-2.0-or-later license and other > > under the GPL-3.0-or-later license. Perhaps this has been mentioned > > somewhere but i did not notice, but is it possible to merge these 2 into > > just GPL-3.0-or-later and thus reduce the specification to only one license? > > Per the licensing guidelines¹ > > The spec file License: field consists of an enumeration of > all licenses covering any code or other material contained > in the corresponding binary RPM. This enumeration must take > the form of an SPDX license expression. No further analysis > as to the "effective" license should be done. > > ¹ https://docs.fedoraproject.org/en-US/legal/license-field/#_basic_policy Yeah, this is a change from previous guidance. Instead of trying to calculate the effect, just state what's there. Even if it makes the expression kind of long and unwieldy. -- Matthew Miller Fedora Project Leader ___ 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: FontAwesome6 (Self-Contained Change proposal)
> Some user-facing applications will be able to display the latest > versions of the FontAwesome icons, which have undergone a number of > updates and cleanups to provide a more pleasing look. In addition, > many new icons have been added in the 5.x and 6.x versions. For > example, version 6.x contains a Fedora icon, while previous versions > do not. Version 5.x contains an an unauthorized not-so-great single-color hackup of the "classic" logo. Version 6.x contains an authorized rendition of the legit current logo. Is 6.x backwards compatible with 5? -- Matthew Miller Fedora Project Leader ___ 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: Changes to Bugzilla API key requirements
On Thu, Feb 23, 2023 at 05:35:36AM +0100, Kevin Kofler via devel wrote: > IMHO, Fedora really needs its own bug tracker that is not driven by this > kind of enterprise-grade security requirements. The "good news" is that Red Hat has announced a move away from Bugzilla for future products. (They're going to Jira.) RH Bugzilla isn't officially shut down, but its days are numbered. We need to come up with something else. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Wed, Feb 22, 2023 at 10:33:27AM -0800, Kevin Fenzi wrote: > Just FYI, we do not produce drpms for rawhide/branched at all (since > 2017 ish). [...] > Its one line in bodhi pungi config: > createrepo_deltas = False > > If shut off, can it be turned back on again (in case of Regrets)? > Just change the one line back to True (well, it's more complex because > we only actually do drpms for the 'Everything' repo, not others, but > it's one line). So, it sounds like "remove the step in the release SOP to turn them _on_ for the branch at release time" would be the easiest way to go. And the default config could be changed in DNF at any time for F38+. It doesn't sound like it's really worthwhile to bother changing F36 or F37. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Wed, Feb 22, 2023 at 10:56:53AM -0500, Demi Marie Obenour wrote: > > Could we do this as a two-step approach? First change the default to > > not use deltas but still allow people to opt-in to it. Then (assuming > > we can track this, which maybe we can't) see how much they're used > > before we decide to pull the plug on producing them. > That would be absolutely awesome. I don't think we can actually tell easily. Additionally, we can't actually tell the important thing, which was "how useful were they really?" — if we have a million people using them but getting an average 0.01% size benefit... that probably doesn't outweigh the costs. But, we _can_ tell (again, see previous discussion) that what we're currently providing is really unlikely to be very useful. So, I'm not actually sure this approach buys us anything. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Wed, Feb 22, 2023 at 01:41:43PM +0100, Luna Jernberg wrote: > Dislike -1 This kind of "vote" isn't really very helpful. Of course not everyone is going to like everything. As I said initially, it's unfortunate that we aren't in a better place here. But we're in the place we're in. If you have a constructive, alternate proposal, let's hear that, please. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Wed, Feb 22, 2023 at 06:18:23AM -0500, Neal Gompa wrote: > Please don't try to equate those things to DeltaRPMs, unless you're > trying to equate their general uselessness. OSTree and Neal, hyperbole like "general uselessness" is not appropriate in talking about other people's work. In any case, CoreOS is our fourth-most-common variant at this point, so clearly some people are finding it useful. > "container-delta" stuff is not generally useful or applicable for > Fedora users and they won't be for a very long time. Maybe, depending on your definition of "very long time". There is work in the right direction, and supporting that can only help. -- Matthew Miller Fedora Project Leader ___ 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: Proposal: drop delta rpms (for real this time)
On Tue, Feb 21, 2023 at 04:44:31PM -0500, Stephen Smoogen wrote: > So do we kill it for: > > F39/F40 and beyond? > F38 and beyond? > X-date and all releases? My normal response would be... well, I missed the F38 change deadline by a wide margin, so F39+. But, I think we could stop producing deltarpms for current releases without really affecting those releases (there would just not be more created, which as previously explored, would not really have a strong effect). So... I wouldn't leave the other options out of the question. What do infra / releng folks think? How easy is it to shut things off? If shut off, can it be turned back on again (in case of Regrets)? Once shut off, is decomissioning infrastructure around it a Project, or just more shutting off? What risks are there? And... how much would be saved in: * compute resources * storage * delays * ongoing maintenance work * other? -- Matthew Miller Fedora Project Leader ___ 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
Proposal: drop delta rpms (for real this time)
I was asked to weigh in on https://pagure.io/releng/issue/7215 as a priority. Last time we talked about this we didn't really get anywhere... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E ... and that ticket hasn't moved, because fixing it isn't trivial. What we're doing now — as has been the case for several years, already noted in the previous discussion — has very little end-user value. Also as noted in that thread (as in the ticket)... that's unfortunate, because it did bring some real benefits (and could possibly do even more.) But, I think it's time to move on. We have ostree and various container-delta approaches. We should focus on those — and give DeltaRPMs a sad, fond farewell. -- Matthew Miller Fedora Project Leader ___ 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
Please join in planning Fedora's next 5-year strategic plan
I hope everyone here follows the Fedora Community blog one way or another, but I know there are lot of things to follow, so posting this here too. From https://communityblog.fedoraproject.org/help-shape-the-fedora-strategy/ The Fedora.Next strategy was a key part of the success we’ve enjoyed over the last few years. But we can’t stop there. It’s time to develop a strategy to meet our goal for the next five years: doubling the number of active contributors. To do this, there are a number of technical and community objectives we need to drive. It looks like that number is 18. The Fedora Council developed a list of 18 objectives to support the impacts we’re looking for. Now it’s your turn. Let us know what you think in the Discussion thread: https://discussion.fedoraproject.org/t/43618 This is just the first step. We’re looking for discussion at a high level. Over the next few months, we’ll have a thread dedicated to each objective. Once we’ve had a chance to discuss it together, the Council will vote on the final strategy. From there, we’ll start working on the details to make these objectives a reality. I’m super excited to work on this with you. Again, that's: https://discussion.fedoraproject.org/t/43618. Hope to see you there. If you're new to Fedora Discussion, you may want to start with * Navigating Fedora Discussion — Tags, Categories, and Concepts: https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/3 * Tips and tricks: what do you need to know about Discourse platform https://discussion.fedoraproject.org/t/tips-and-tricks-what-do-you-need-to-know-about-discourse-platform/24773 * Guide to interacting with this site by email https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960 -- Matthew Miller Fedora Project Leader ___ 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
SIG status, visibility, etc. [Re: Risc-V SIG?
On Thu, Feb 09, 2023 at 09:51:37AM -0800, Kevin Fenzi wrote: > Yep. Sigs exist because they say they do. ;) > > The risc-v sig has been around for a while, but I guess a sig wiki page > was never made. :( I like that we have low barriers to entry for SIGs, but we end up with a lot of empty storefronts — or enthusiastic groups of people who aren't quite sure what to do next after creating a wiki page. We actually talked about this very issue at the Fedora Council hackfest last week, and it's one of the things we want to take on as part of Strategy 2028. And, this is the third time today that this has come up for me, from totally different directions. Marie is working on a redesign for the high-level org chart, and that lists a few kind of arbitrary SIGs and not others — see https://discussion.fedoraproject.org/t/fedora-org-chart-update-re-design-looking-for-feedback/46425/1 And Peter Boy for the docs team was asking about whatcanidoforfedora.org, which has kind of the same problem: what groups are teams are active, what is the current information, etc. We had hoped to solve this with the sadly doomed Fedora Hubs project (https://fedoramagazine.org/fedora-hubs/), and then with Taiga (https://communityblog.fedoraproject.org/retiring-taiga-instance-on-teams-fedoraproject-org/) and then simply by trying to maintain lists: * https://docs.fedoraproject.org/en-US/engineering/ * https://docs.fedoraproject.org/en-US/mindshare/ .. which clearly also isn't working. If anyone is interested in tackling this, I'd love to hear your thoughts (either now, or save them up for when we get to planning the details of that part of the strategy). -- Matthew Miller Fedora Project Leader ___ 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: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 10:00:22AM -0800, Adam Williamson wrote: > No, that's the promise of Fedora Flatpaks, which is an effort with a > distinct identity and philosophy (but which is, uh, not being its best > possible self so far, I think everyone would agree). It's not the Joining this discussion late (I plead "FOSDEM"), but I want to chime in on this -- I do agree, and think that making that better should be a focus. Not only will this make things better on Fedora Silverblue (and others), but it also is a way we can expand our reach -- we can bring the benefits of distro packaging (with, you know, guidelines and policies and transparency and so on) to people who might be running a different distro underneath. (And then hopefully coax them over entirely. I mean, if they want. No pressure.) -- Matthew Miller Fedora Project Leader ___ 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: Porting Fedora for the LoongArch architecture.
On Tue, Jan 10, 2023 at 11:12:22PM +0800, 孙海勇 wrote: > I want to add LoongArch to the official Fedora support architecture, This is really cool -- welcome, and I'd love to help make sure you succeed! > I'm currently a newbie in the Fedora community, so I need help from > community developers, and would like someone to guide me on what to do > next, such as what would be a better time to submit necessary patches to > packages in the Fedora repository, how to develop in a collaborative > manner, what other systems to be used for management, etc. In short, any > information would be useful. Could I get help here? :) This message is a good start! There is a little bit of information here https://fedoraproject.org/wiki/Architectures, but it's not really complete. I'm afraid a lot of the knowledge is really held in a few people's heads. Hopefully we can get you connected with the right people! -- Matthew Miller Fedora Project Leader ___ 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: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
On Mon, Jan 09, 2023 at 10:08:11PM +0100, Mark Wielaard wrote: > > ... and I won't quote all of that, but looking at > > https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy... > > I don't see any violations, either in the letter or the spirit of what is > > written. [...] > It does feel to me as being against the spirit, and only not against > the letter because it is presented as a "revote" on an existing change > proposal instead of proposing a new change proposal (which this really > is IMHO). To be clear -- I don't think what happened is in conflict with the _FESCo_ policy about tickets (see link above). FESCo does not, as far as I can see, have any specific policies about how votes related to a Change should be conducted. And I don't think there is a general "FESCo can never reconsider decisions!" rule. But like I said, I _don't_ think this revote was as visible or transparent as it should have been, and I agree that that doesn't really fit with the intention of the Changes policy. > Socially I think it will be better for all involved if the policies on > revoting and/or reintroducing a change proposal are first clarified > before allowing a revote. At the moment everybody involved seems hurt > because of the unclear policy. Not having clear rules on the needed > visibility and time needed to discuss this revote/resubmission of the > change proposal caused people to assume the worst about others. Lets > reset and take the time to heal first, so people start actually > talking about real solutions again. Yep, I definitely agree with this. -- Matthew Miller Fedora Project Leader ___ 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
FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote: > PS: The impression I get is that everything was deliberately rigged so that > the vote would end up the way it did: > > 1. A new ticket was filed, in order to exclude the participants of the > previous discussion. > 2. The people watching the old ticket were NOT notified. > 3. The Tools Team was NOT notified. > 4. The proponents of the Change, on the other hand, WERE notified. I agree with your earlier post that this did not have enough visibility, enough notice, or enough time. I was certainly taken by surprise, and I was trying to keep an eye on this one in particular. (Having the discussion under "Schedule for Tuesday's FESCo Meeting" didn't help it jump out at me either.) BUT, I do not think it was done with malice, as "deliberately rigged" implies. I don't see that at all -- I see excitement and interest in moving forward on something that already has taken a long time, and looming practical deadlines. > Therefore, I hereby request that the vote be annulled as having happened > in violation of the Change policy. So, from a purely "what are the rules?" view, the Change process says: FESCo will vote to approve or deny a change proposal in accordance with the FESCo ticket policy. ... and I won't quote all of that, but looking at https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy... I don't see any violations, either in the letter or the spirit of what is written. And, from a practical point of view, since this passed with six +1 votes, I'm not sure what benefit canceling and re-voting would really add. It might be useful to improve both the documented policies. The Changes policy has nothing about reconsidering Changes in the current cycle that I can see. (Or, actually, for that matter, for resubmitting in future cycles either, unless i'm missing something.) And the FESCo ticket policy could include a) some steps for wider communication, and b) maybe something about holidays and other times which might need special consideration. Most crucially, let's please drop the idea that anyone is acting out of malice. I'm quite sure that everyone arguing passionately on both sides of this issue has the best interest of Fedora and of Fedora Linux users in mind. Let's all keep that framing in mind in the ongoing discussion. Thank you. -- Matthew Miller Fedora Project Leader ___ 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Mon, Jan 02, 2023 at 01:06:52PM +0100, Kevin Kofler via devel wrote: > Matthew Miller wrote: > > Okay. no. This is not how we do things here. > Apologies for my snide remark that visibly came out rude, sorry. Thank you, Kevin. -- Matthew Miller Fedora Project Leader ___ 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Mon, Jan 02, 2023 at 01:59:46AM +0100, Kevin Kofler via devel wrote: > The application can pick the options with which each library is compiled? > What a stupid idea! Now I understand why the language is called "Rust". Okay. no. This is not how we do things here. -- Matthew Miller Fedora Project Leader ___ 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: Self Introduction: Jeff Stewart
On Sun, Nov 06, 2022 at 01:18:23PM -0800, jeff stewart wrote: > Hello I am a Linux Systems Administrator at spacex, and have over 6 years > of IT experience. I love Linux and hope to learn from the best at fedora! I > am very willing to jump in and help anyway that I can. It will be nice to > talk to you all! Cool! Welcome! What kind of things are you interested in? If you'd like to exercise your sysadmin skills, Fedora Infrastructure https://docs.fedoraproject.org/en-US/infra/ is probably the place. Or, if you're more interested in something else... there's a lot! -- Matthew Miller Fedora Project Leader ___ 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: FontAwesome 6
On Fri, Nov 04, 2022 at 03:35:14PM -0600, Jerry James wrote: > On Fri, Nov 4, 2022 at 8:24 AM Matthew Miller > wrote: > > This is particulary nice for Fedora, since v6 includes our new logo! > Great! Do you happen to be a web developer, or play one on TV? :-) I have a hand-coded html personal website. I am not sure if that answers your question, and if it does, in which direction. :) The real answer is: I am not. But the not-so-great stand-in logo they'd generated was one of the drivers for the redesign, so I'm glad to see it come out. -- Matthew Miller Fedora Project Leader ___ 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: [Rust] Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Tue, Nov 01, 2022 at 01:30:01PM -0500, Michel Alexandre Salim wrote: > I've finally gotten round to doing some polishing and getting it > packaged: > - updates for Fedora 36, 37, and Rawhide: > https://bodhi.fedoraproject.org/updates/?search=rust-update-set-0.0.1=python-rust-update-set > - Pagure repo: https://pagure.io/fedora-rust/rust-update-set > > There are some fixes for corner cases I encountered while trying to update our > `below` packages with this, and some changes needed to get this packageable, > but those are minor. It mostly works really well, and is at a stage where > hopefully people can take a look and make suggestions for improvements. Cool -- glad to see this! -- Matthew Miller Fedora Project Leader ___ 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: systemd 252 feature: SUPPORT_END in /etc/os-release
On Tue, Nov 01, 2022 at 08:22:55PM -0400, Ben Cotton wrote: > I'm happy to make this the Fedora Program Manager's responsibility, > but if RelEng wants to own that, that's fine too. In fact, if it > doesn't cause RelEng to break into a cold sweat, I'd be happy to be > added as a maintainer to make the updates directly. Otherwise, I'll > file PRs and pester until they're merged. :-) Excellent. Making more work for people was my main concern, but if the people who would do the work are signed on, that's not an issue. :) -- Matthew Miller Fedora Project Leader ___ 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: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Tue, Nov 01, 2022 at 09:18:19AM -0400, Colin Walters wrote: > > Would it make sense to have a Fedora Objective (at the Council level) around > > this? > > Probably? > > I would say actually that this proposal is not even the end. I cut out a > part due to objections/concerns, but I personally (still) want to get rid > of e.g. the Silverblue/Kinoite/CoreOS type "sub-brands". It's just e.g. > "Workstation, but in image+container-default mode" - where it even > matters. Otherwise one can just say "I run Fedora". This is revisiting > https://discussion.fedoraproject.org/t/its-more-fedora-than-it-is-fedora-noun/33864 > in effect - I personally think "we'll actually just do what you asked for > when you type dnf -y install cowsay" is a notable leap here. While I will carefully skirt the terminology issue, I love the vision. Let's talk more about making an Objective around this. -- Matthew Miller Fedora Project Leader ___ 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: FontAwesome 6
On Mon, Oct 31, 2022 at 12:23:02PM -0600, Jerry James wrote: > package. Version 6.x has backwards compatibility helpers for both 4.x > and 5.x, so I would like to see fontawesome-fonts upgraded to 6.x and > the fontawesome5-fonts package retired. There are a few hurdles to This is particulary nice for Fedora, since v6 includes our new logo! -- Matthew Miller Fedora Project Leader ___ 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: Deprecating intents in Modularity
On Wed, Nov 02, 2022 at 04:45:41PM +0100, Petr Pisar wrote: > Hello module maintainers, > > do you know intents > <https://github.com/fedora-modularity/libmodulemd/blob/8f7543f712c4aeb8afd795cfc7c34ee8cbe05e67/yaml_specs/modulemd_defaults_v1.yaml#L25>? > I believe you don't. Do you use intents? I hope you don't. > > In modularity, default streams and default profiles can be parametrized by > a system role (purpose, variant, spin). Modularity calls it an "intent". > > Theoretically, if you install Fedora Workstation and then install a postgresql > module, client libraries or tools for PostgreSQL could be installed. While > installing the same module on a Server spin would instead install PostgreSQL > server. Or, for example, if we had a "personal productivity apps" module, and you had KDE Plasma installed, you'd get a KDE-flavored set of these apps, while if you had GNOME Shell you'd get gtk ones. :) That said... obviously we didn't get there. So I am fine with dropping this feature. -- Matthew Miller Fedora Project Leader ___ 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
systemd 252 feature: SUPPORT_END in /etc/os-release
See: https://lists.freedesktop.org/archives/systemd-devel/2022-October/048519.html Systemd will set the taint flag 'support-ended' if it detects that the OS image is past its end-of-support date. This date is declared in a new /etc/os-release field SUPPORT_END= described below. [...] os-release gained a new field SUPPORT_END=-MM-DD to inform the user when their system will become unsupported. Should we set this? I kind of think we should. I would suggest we set it to the expected EOL based on the nominal schedule. We could either release updates to extend it if we slip... or... just not do that. -- Matthew Miller Fedora Project Leader ___ 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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
e to lead the way — and then we can > > maybe expand to Go, which has similar issues, and then Java (where, you > > know, things have already collapsed despite heroic effort.) > > Oh, actually, I don't think Rust packaging is a good place to start > here at all. :) > > The way cargo works already maps very neatly onto how RPM packages > work, which is definitely *not* the case for other language > ecosystems. I also think we could even massively improve handling of > "large" projects with many sub-components (like bevy, zola, wasmtime, > deno, etc.) - which are currently the only projects that are "painful" > to package - *without* completely changing the underlying packaging > paradigm or distribution mechanism. (I've been wanting to actually > write better tooling for this use case, but alas, Bachelor thesis is > more important for now.) I think we can both be right, here: the simple mapping seems like it makes it good to experiment with. > alternatives, all attempts at trying different approaches (maven > artifacts in koji, vendoring NodeJS dependencies, Java Modules, etc.) > have *failed* and ultimately made things worse instead of improving > the situation - the only thing that has proven to be sustainable (for > now) is ... maybe surprisingly, plain RPM packages. I'll take "for now". :) -- Matthew Miller Fedora Project Leader -- Matthew Miller Fedora Project Leader ___ 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: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Tue, Oct 25, 2022 at 09:00:40AM -0400, Colin Walters wrote: > Two things: > > - This proposal is explicitly trying to tie everything together. I think > without the "bigger picture", it's actually *more* confusing. For example, > just pushing the container images does little unless we invest in them as a > derivation source and build tooling and docs around them. > - At a very practical level, I find context switching in Mediawiki syntax to > be rather tedious. I'd prefer to discuss the individual sections in the > already extant tracker issues that accept Markdown and have a well-understood > and used discussion mechanism. (Or of course, email here) > > But you're certainly not wrong, it *is* a big proposal. Happy to make > changes, I'm mainly just saying there already are dedicated sub-proposal > trackers to discuss the details of those. Would it make sense to have a Fedora Objective (at the Council level) around this? -- Matthew Miller Fedora Project Leader ___ 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: F38 proposal: Modernize Live Media (System-Wide Change proposal)
On Wed, Oct 19, 2022 at 09:22:23AM +0200, Vitaly Zaitsev via devel wrote: > I don't think that persistence by default is a good idea, because > modern USB-flash drives are very unreliable and don't have a > wear-cell balancer, so it will wear out very quickly for some > frequently modified files. Yeah — lots of very-low-quality flash drives out there. Ran into this just trying to get decent ones for give-away swag. I expect this to get worse and worse, as more and more people just use dropbox and other cloud storage for file transfer and random storage. Once again we're increasingly a niche case. (It is, on the other hand, easier and easier to get really good MicroSD cards for relatively cheap. SanDisk High Endurance for ten bucks. But not quite cheap enough for giveways. Maybe the giveway item should be a branded card reader...) -- Matthew Miller Fedora Project Leader ___ 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
Amazon mirrors [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Wed, Oct 19, 2022 at 10:50:19AM +0200, Sandro wrote: > >We don't have a "main mirror" for that to work. > > So, this has been looked into already? It definitely sounds like it > could help in sparsely served parts of the world at a reasonable > cost. Yes. I think this is basically just a matter of _doing_. -- Matthew Miller Fedora Project Leader ___ 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
musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
s because the barrier to participation seems too high. It's not because it's statically-linked binaries [2] can't or shouldn't exist in Fedora — that's not one of our core principles! In fact and quite to the contrary, we need to adapt to handle this amazing open source success story better. And, I led with: I appreciate all the work you've all done to make this work. That's definitely true — I think it was super-valuable to pilot this approach. But I think that the Rust ecosystem would be a great place to pilot a different way. Something lightweight where we cache crates and use them _directly_ in the build process for _application_ RPMs. Rust packages include a lot of machine-readable metadata. We should be able to watch for CVEs, RustSec, and other security notices even without encoding the metadata in RPMs. License review could also be automated — the field in Cargo.toml is supposed to be SPDX, so that's convenient. [3] We could also attach other metadata to the packages in the cache. Maybe some popularity, update frequency from Cargo.io, but also package review flags: checked license against source, and whatever other auditing we think should be done. This moves the focus from specfile-correctness to the package itself, and the effort from packaging to reviewing. (I'd suggest that for the experiment, we not make any deep auditing manditory, but instead encouraged.) And these flags should be able to be added by anyone in the Rust SIG, not necessarily just at import. Maybe we could get involved in Cargo Vet [4] — we could be both a consumer _and_ a data source. Fedora _needs_ to adapt to stay relevant in the world where every language stack has developed a packaging ecosystem which effectively ignores us. Some of them are missing lessons they could have learned, ah well — but they also have a lot of nice new ideas we're missing. And, no matter what we think, we're clearly not going to stop them. Rust packaging seems like a great place to lead the way — and then we can maybe expand to Go, which has similar issues, and then Java (where, you know, things have already collapsed despite heroic effort.) What do you all think? -- [1] https://archive.org/details/sim_byte_1990-10_15_10/page/n249/mode/2up [2] Also, actually: https://docs.rs/bevy_dylib/0.8.1/bevy_dylib/. They don't recommend this for release builds... but that looks to be mainly for distribution reasons we could easily handle? [3] https://communityblog.fedoraproject.org/important-changes-to-software-license-information-in-fedora-packages-spdx-and-more/ [4] https://mozilla.github.io/cargo-vet/ -- Matthew Miller Fedora Project Leader ___ 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
http[s] mirrors [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
On Thu, Oct 13, 2022 at 03:57:41PM +0200, Kevin Kofler via devel wrote: > > Also, a ton of Fedora mirrors still don't use HTTPS for various reasons. > I would say that those mirrors ought to be kicked out of the mirror list > immediately. There are also a lot of rsync mirrors. I don't think any of them are using rsync-ssl. I think "kicked out" is a bit harsh -- but we should definitely suggest it. And I think we should also do the metadata signing as soon as practical... defense in depth and all that. -- Matthew Miller Fedora Project Leader ___ 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: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?
On Sun, Oct 09, 2022 at 05:17:29AM +0200, Kevin Kofler via devel wrote: > IMHO, we need a proper solution for the general comps issue rather than that > half-baked compromise that does not really improve the situation. KDE Plasma I agree -- comps has a lot of problems which limit our flexibility, and doesn't really even expose useful collections to users. I'd love to see a modern replacement. -- Matthew Miller Fedora Project Leader ___ 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
Important changes to software license information in Fedora packages (SPDX and more!)
On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format - The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? -- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! --- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/ -- Matthew Miller Fedora Project Leader ___ devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Important changes to software license information in Fedora packages (SPDX and more!)
On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format - The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? -- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! --- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/ -- Matthew Miller Fedora Project Leader ___ 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: Some spins/labs to be dropped from F37
On Thu, Jul 21, 2022 at 10:25:25AM -, Artur Frenszek-Iwicki wrote: > > * Games Spin — https://fedoraproject.org/wiki/Games_Spin > Unless someone more experienced comes along, I'd be willing > to take a shot at maintaining the games spin. This is how someone becomes experienced. :) -- Matthew Miller Fedora Project Leader ___ 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
