[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c126e4af73 chromium-112.0.5615.121-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing yapet-2.6-1.el7 Details about builds: yapet-2.6-1.el7 (FEDORA-EPEL-2023-3ece9cfc6a) Yet Another Password Encryption Tool Update Information: Update to 2.6 ChangeLog: * Fri Apr 21 2023 Greg Bailey - 2.6-1 - Update to 2.6 - Remove unnecessary patch * Sat Jan 21 2023 Fedora Release Engineering - 2.3-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Sat Jul 23 2022 Fedora Release Engineering - 2.3-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Sat Jan 22 2022 Fedora Release Engineering - 2.3-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Tue Sep 14 2021 Sahana Prasad - 2.3-9 - Rebuilt with OpenSSL 3.0.0 * Fri Jul 23 2021 Fedora Release Engineering - 2.3-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Thu Jan 28 2021 Fedora Release Engineering - 2.3-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Wed Jul 29 2020 Fedora Release Engineering - 2.3-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jan 31 2020 Fedora Release Engineering - 2.3-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Dec 14 2019 Jeff Law - 2.3-4 - Fix mising #includes for gcc-10 * Sat Jul 27 2019 Fedora Release Engineering - 2.3-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Mon Mar 18 2019 Remi Collet - 2.3-2 - rebuild for libargon2 new soname ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-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 07:21:54PM -0400, Simo Sorce wrote:
...snip...
> Unless this discourse has some great mail bridge (it doesn't) or maybe
> an rss feed (I do not use those at work, but I guess I could ?) So that
> I can skim messages on my terms, I think I (and those like me) will be
> the next "missing people".
So I've been using the email bridge for a while (I think since we set it
up) and it's got it's issues for sure, but I am not sure if it's as bad
as folks fear.
https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-by-email/25960
has general info.
I had just been dumping it into one mailbox, but today I poked at
getting it sorted better. For those of you ancient dinosaurs like myself
still using procmail (written in 1990!), the following hacky recipe
works for me:
:0
* ^List-Id: .*<\/[-a-z0-9]*\.discussion\.fedoraproject\.org>
{
NAME=`echo "${MATCH}" | sed
's/\.discussion\.fedoraproject\.org>$//'`
:0
$HOME/Maildir/.fedora.discussion.$NAME/
}
This gets posts flowing into folders by list-id, so:
.fedora.discussion.Ask-Fedora_Ask-in-English/
.fedora.discussion.Project-Discussion/
And of course you can filter more with the actual tags from there if you
like. Posts should work fine as they have a reply-to hash with the
topic/post and who the email was sent to.
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.
For rss feeds, you can in general add '.rss' to any url on the forum.
ie, https://discussion.fedoraproject.org/tag/guide.rss will give you a
rss feed of all the things tagged '#guide'.
Also, there's a 'latest posts' feed at:
https://discussion.fedoraproject.org/posts.rss
This should be all posts as they come
and a latest topics at:
https://discussion.fedoraproject.org/latest.rss
which is just the topics as they come (ie, the new/initial post in each
thread).
I've also been using the rss feeds for a long while and they seem fine
and reliable.
As a side note, I use RSS for tons of things. My setup is to run
miniflux ( https://miniflux.app/ ) on my main server at home, then I
use newsflash on my laptop or an android miniflut on android to read
feeds. YMMV.
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: No koji builds during mass branching and updates-testing enablement
On Fri, Apr 21, 2023 at 09:03:11PM +0200, Fabio Valentini wrote: > On Thu, Mar 9, 2023 at 8:56 PM Kevin Fenzi wrote: > > > > * Cancel all builds that are in progress. Maintainers can resubmit after > > the outage with the appropriate branches. > > * unpush all updates stuck in gating/pending? Is this too much? > > * do the branching steps, get everything in place, then open things on > > the hub. > > > > This is a lot more disruptive, but it's only for part of a day and I > > agree it's nicer to not have things to clean up. > > Sorry for the long RTT. My email inbox is only now no longer looking > like a dumpster fire. :) > > It sounds like koji actually supports giving an outage message, so > that would be great. > Concerning the three steps listed above: I think they would make sense. > Maybe it could look like this: > > 1. lock down the koji hub > 2. cancel all builds that are still running (I think this could > exclude builds that are targeting stable branches?) > 3. unpush all Rawhide updates that are stuck (maybe adding a comment > to the bodhi update why it happened) > 4. do the mass branching steps (i.e. Rawhide == Fedora N+2, Branched > == Fedora N+1) > 5. unlock koji hub > > Parts of steps 2,3,4 could even happen with more granularity (I think > mass branching steps happen alphabetically for all packages? that > would give running builds more time to finish.). This seems doable. We should make sure it is as best we can, and then probibly announce it before the next mass branching so everyone knows to expect it. :) Hopefully this will prevent problems the next time... Adding Tomas here on cc kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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, 2023-04-22 at 10:37 -0700, Kevin Fenzi wrote: > On Fri, Apr 21, 2023 at 02:30:45PM -0700, Adam Williamson wrote: > > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote: > > > > > > > For lists that are active, the split is confusing — when should > > > > something be on the packaging list rather than devel? What happens when > > > > something is related to both Cloud and Server, or Workstation and KDE? > > > > One can post to both lists, but if someone replies and isn’t subscribed > > > > to both, the conversation gets split. > > > > > > Do Fedora mailing lists reject mail from non-members, and redirect > > > follow-ups? > > > > Many lists *hold* mail from non-members, because mailing lists get tons > > of spam. So the mail won't get through until an admin approves it. That > > might happen right away...or it might happen in two days, when the mail > > is no longer relevant. We can't really just let all mails from non- > > members through because...spam. > > Right. I don't think we have many (or possibly any) lists that still > hold email from non-members. The flood of spam is just too high for that > for the last N years. So, almost all our lists are set to reject non > member posts. :( ah, I hadn't noticed that change :/ I could've sworn I still sometimes get hold notices when I send meeting announcements to lists I'm not subscribed to... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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 06:03:12PM +0100, Richard W.M. Jones wrote: > > I would also be one of those people who would be much less engaged -- > even disengage -- if everything moved to a website. > > I have one thing to add that I don't think was covered: > > Can we make contributing to the mailing list easier? > > One thing we have done in a community I manage is *not* to require any > sign up to the mailing list before posting. They are invited to > simply email the list address. The flip side to this is obviously > that "someone" (cough, me) has to filter out a lot of spam carefully. > It's not too bad in that small community, but might be a lot more work > in Fedora. But it ought to reduce the barrier to entry to "able to > send an email" which is IMHO pretty low. We used to do this for a long time, but it became untenable a number of years ago. When you look at there's 10 posts to look thru for legit non members thats fine, when you look and there's 10,000... :( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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:20:37PM -0400, Matthew Miller wrote: > 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. 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. > 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]). [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. > 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. Ack. There's also https://pagure.io/fesco/issue/2982 on the same topic now. > For right now, though: let’s discuss — on the list! Thank you for this detailed proposal. I think it was very clear and even and written in a way that led the discussion in good directions. Zbyszek ___ 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 02:30:45PM -0700, Adam Williamson wrote: > On Fri, 2023-04-21 at 23:20 +0200, Florian Weimer wrote: > > > > > For lists that are active, the split is confusing — when should > > > something be on the packaging list rather than devel? What happens when > > > something is related to both Cloud and Server, or Workstation and KDE? > > > One can post to both lists, but if someone replies and isn’t subscribed > > > to both, the conversation gets split. > > > > Do Fedora mailing lists reject mail from non-members, and redirect > > follow-ups? > > Many lists *hold* mail from non-members, because mailing lists get tons > of spam. So the mail won't get through until an admin approves it. That > might happen right away...or it might happen in two days, when the mail > is no longer relevant. We can't really just let all mails from non- > members through because...spam. Right. I don't think we have many (or possibly any) lists that still hold email from non-members. The flood of spam is just too high for that for the last N years. So, almost all our lists are set to reject non member posts. :( kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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, 22 Apr 2023 at 13:03, Richard W.M. Jones wrote: > > I would also be one of those people who would be much less engaged -- > even disengage -- if everything moved to a website. > > I have one thing to add that I don't think was covered: > > Can we make contributing to the mailing list easier? > > One thing we have done in a community I manage is *not* to require any > sign up to the mailing list before posting. They are invited to > simply email the list address. The flip side to this is obviously > that "someone" (cough, me) has to filter out a lot of spam carefully. > It's not too bad in that small community, but might be a lot more work > in Fedora. But it ought to reduce the barrier to entry to "able to > send an email" which is IMHO pretty low. > > Fedora mailman gets a lot of emails. Generally we would see about 900 emails per day that would need to be dealt with per day for the devel list and 1600 emails per day for users. The lower end mailing lists see about 200 emails a day that come in and get dropped from non-subscribers. Processing those is not a fast issue with mailman3 because of database and schema issues. It generally takes 20 to 30 seconds to delete or accept a held email. Trying to do them in bulk halts ALL other transactions as it has to lock various tables. Some of these issues may be fixed in a newer version of mailman3, but we can't just update to any newer version because our database schema was a prerelease. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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 06:03:12PM +0100, Richard W.M. Jones wrote: > > I would also be one of those people who would be much less engaged -- > even disengage -- if everything moved to a website. > > I have one thing to add that I don't think was covered: > > Can we make contributing to the mailing list easier? > > One thing we have done in a community I manage is *not* to require any > sign up to the mailing list before posting. They are invited to > simply email the list address. The flip side to this is obviously > that "someone" (cough, me) has to filter out a lot of spam carefully. > It's not too bad in that small community, but might be a lot more work > in Fedora. But it ought to reduce the barrier to entry to "able to > send an email" which is IMHO pretty low. See smooge's reply here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQSYAFVGT4IGMSXCQEH3TRPYCIWYWZLM/ Zbyszek ___ 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
[Bug 2188829] perl-Pod-Parser-1.66 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2188829
--- Comment #1 from Upstream Release Monitoring
---
Scratch build failed. Details below:
GenericError: File upload failed:
cli-build/1682184432.3854659.bEOhuKBa/perl-Pod-Parser-1.66-1.fc36.src.rpm
Traceback:
File
"/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3110, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3034, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))
If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2188829
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2188829] New: perl-Pod-Parser-1.66 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2188829 Bug ID: 2188829 Summary: perl-Pod-Parser-1.66 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Pod-Parser Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.66 Upstream release that is considered latest: 1.66 Current version/release in rawhide: 1.65-5.fc38 URL: http://search.cpan.org/dist/Pod-Parser/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3244/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Pod-Parser -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2188829 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-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
I would also be one of those people who would be much less engaged -- even disengage -- if everything moved to a website. I have one thing to add that I don't think was covered: Can we make contributing to the mailing list easier? One thing we have done in a community I manage is *not* to require any sign up to the mailing list before posting. They are invited to simply email the list address. The flip side to this is obviously that "someone" (cough, me) has to filter out a lot of spam carefully. It's not too bad in that small community, but might be a lot more work in Fedora. But it ought to reduce the barrier to entry to "able to send an email" which is IMHO pretty low. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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:38:28PM -0400, Ben Cotton wrote: > On Fri, Apr 21, 2023 at 4:05 PM Maxwell G wrote: > > > > What evidence shows that the group is ever shrinking? I often see Self > > Introduction posts and new people interacting with project. I suppose > > that whether they continue interacting afterwards is another question. > > I'm glad you asked. Earlier this week I decided to avoid doing other > work by putting together some quick charts of devel list > participation. Here's the number of unique participants per month from > 2004–2022: > https://bcotton.fedorapeople.org/images/devel-participation-monthly.png > > And for a less-noisy version, the median of the monthly numbers per year: > https://bcotton.fedorapeople.org/images/devel-participation-mean.png 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. Zbyszek ___ 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: > > But with my Fedora Ambassador hat on I can tell you that the problem > we see right now is not that we don't have people coming to Fedora. We have > a problem helping people to connect to where the work is happening in a way > that they can contribute. > > 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.] > 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 > ways that people can contribute, I'm curious what the roadblocks you are > seeing for people wanting to get into development. I can completely > understand if someone wants to join mindshare, D, outreachy, or docs, > etc... that they might find a mailinglist to cumbersome to work with. Have > you run into sitautions where people wanted to get involved in development > but were having issues with a mailing list? All those things are *development*. Without infra and docs and people and communication, the remaining development "core" would mean very little. And to make the project effective we absolutely need to cooperate and coordinate across all those teams. So if we have whole groups of people who find [some communication medium] tedious, it is a very strong argument against that medium. (I'm still reading the thread and haven't made up my mind, but if anything, this part of the discussion is a strong argument *for* discourse, because there are clear problems with the mailing list approach and it's easier for long-time contributors like you and me to adjust than for newcomers.) Zbyszek ___ 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: Error with libheif package
On 22/04/2023 14:41, Christopher Klooz wrote: So once users have rpmfusion enabled, `dnf install/update libheif` ends up in a conflict because of `libheif-hevc` and `libheif-freeworld`. Already fixed in libheif-freeworld-1.15.1-5. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 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:48 AM Matthew Miller wrote: > 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? That would certainly be convenient and support use cases like with krun, but I'd need to do more research around producing a compatible podman runtime. I've seen a few container runtime integration projects for Firecracker, some abandoned. Maybe pursuing the Kata runtime would be the best fit for Fedora since it's already packaged? (Although I see Kata still wants Firecracker's jailer program, and I don't know if it's optional or not.) Thanks. David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Firecracker microVM manager
On 4/22/23 10:13, David Michael wrote: > On Fri, Apr 21, 2023 at 10:02 PM Demi Marie Obenour > wrote: >> On 4/21/23 11:13, David Michael wrote: >>> Hi, >>> >>> Following up on this, Firecracker has been accepted and submitted to >>> Fedora. Thanks to Fabio for all of the Rust reviews. >>> >>> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b >>> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0 >>> >>> Some quick comments on the TODO from the original e-mail: >>> >>> On Sat, Mar 4, 2023 at 12:40 PM David Michael wrote: - The musl package adds /usr paths for compatibility with the compiler --sysroot option. - The rust compiler adds musl target subpackages. >>> >>> Targeting musl was dropped after the initial discussion, so there is >>> no sandbox or seccomp filter in Fedora until that can be implemented >>> with dynamic linking glibc upstream. I'll keep the Copr repo[0] >>> active for a while to provide musl builds. >> >> 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. Package description perhaps? >> Does the >> sandboxed portion of Firecracker do anything that would require an NSS >> (name service switch) lookup, such as DNS or username resolution? > > I don't think NSS lookups are an issue since the program takes > numerical UID/GID values as command-line arguments. The main breaking > issue with the jailer is that it requires Firecracker to be a single > static binary[1] (which is the musl target's default output upstream). > Their documentation also says glibc isn't supported, but I haven't > tried making a static glibc binary to see what fails. The seccomp > filter being unimplemented for glibc is a separate issue from the > jailer. glibc does not support static linking well. >> If >> not, then I don’t see why musl (which Fedora already ships!) would be a >> problem. > > There is no problem technically; the Copr repo[2] is building > Firecracker RPMs with musl. Maintainers of both Rust and musl seemed > to be against it in Fedora. From this thread: Why does Fedora not want to ship Firecracker statically linked to musl? That is the supported and tested configuration upstream. Using glibc or dynamic linking is not supported for production use. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: Firecracker microVM manager
On Fri, Apr 21, 2023 at 10:02 PM Demi Marie Obenour wrote: > On 4/21/23 11:13, David Michael wrote: > > Hi, > > > > Following up on this, Firecracker has been accepted and submitted to > > Fedora. Thanks to Fabio for all of the Rust reviews. > > > > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b > > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0 > > > > Some quick comments on the TODO from the original e-mail: > > > > On Sat, Mar 4, 2023 at 12:40 PM David Michael wrote: > >> - The musl package adds /usr paths for compatibility with the compiler > >> --sysroot option. > >> - The rust compiler adds musl target subpackages. > > > > Targeting musl was dropped after the initial discussion, so there is > > no sandbox or seccomp filter in Fedora until that can be implemented > > with dynamic linking glibc upstream. I'll keep the Copr repo[0] > > active for a while to provide musl builds. > > 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. > Does the > sandboxed portion of Firecracker do anything that would require an NSS > (name service switch) lookup, such as DNS or username resolution? I don't think NSS lookups are an issue since the program takes numerical UID/GID values as command-line arguments. The main breaking issue with the jailer is that it requires Firecracker to be a single static binary[1] (which is the musl target's default output upstream). Their documentation also says glibc isn't supported, but I haven't tried making a static glibc binary to see what fails. The seccomp filter being unimplemented for glibc is a separate issue from the jailer. > If > not, then I don’t see why musl (which Fedora already ships!) would be a > problem. There is no problem technically; the Copr repo[2] is building Firecracker RPMs with musl. Maintainers of both Rust and musl seemed to be against it in Fedora. From this thread: On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa wrote: > As the musl package maintainer, I don't particularly want Fedora > packages depending on it unless they absolutely have to. > [...] > As in musl is statically linked into the binaries? Or the Rust code is > statically linked. The former is not okay, From the Firecracker package review: On Fri, Apr 7, 2023 at 11:27 AM wrote: > 2. Building for the *-musl Rust targets is not going to be supported in Fedora For what it's worth, Arch and openSUSE seem to be building with glibc and so are in the same position with this package. Without Rust's musl target, the only path forward is to try to improve glibc support upstream. Thanks. David [0] https://github.com/firecracker-microvm/firecracker/blob/main/docs/jailer.md [1] https://github.com/firecracker-microvm/firecracker/blob/v1.3.1/src/jailer/src/env.rs#L380 [2] https://copr.fedorainfracloud.org/coprs/dm0/Firecracker ___ 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, 21 Apr 2023 at 17:20, Florian Weimer wrote: > > > For lists that are active, the split is confusing — when should > > something be on the packaging list rather than devel? What happens when > > something is related to both Cloud and Server, or Workstation and KDE? > > One can post to both lists, but if someone replies and isn’t subscribed > > to both, the conversation gets split. > > Do Fedora mailing lists reject mail from non-members, and redirect > follow-ups? > > Yes we have to. Most of the email coming to any of the fedora mailing lists is spam email from non-subscribers. A good portion of it is 'smart' SPAM where it replies to a specific email with headers to make it pop into an existing thread. Fiddling with various spam controls to better handle that has continually caused important developers emails to start being marked as SPAM. The first thing we did was to have non-member email moderated for the lists. This sounds great but the amount of queued email on many lists is in the order of 100k or more emails. The problem is that the version of mailman3 uses some sort of linked list to keep track of all those queued emails. Every email seems to get checked against that queue which then slows down the overall system. Last year we were getting hour long timeouts on mailman3, and I then spent about 3 man-weeks of volunteer time to go through only about 100 mailing lists to clean out the 100k queues on each of them. I stopped when the timeouts got down to a 'normal' amount but the amount of junk email on the many email lists is a lot. There are probably ways to do this directly in the postgres database, but my attempts required restores from backups due to 'differences between our beta setup and what is expected'. Trying to upgrade mailman3 to a version which may be better has been,I think, a 5 year task of continual frustration. When I was in infrastructure, everyone always had about 10 other tasks of higher priority that HAD to be done to keep other parts of Fedora running. When I left infrastructure, that increased the tasks for the remaining people to 20. Hiring in a replacement just found more things which needed to be kept running so we have looked for volunteers for a while. Several attempts have been made by volunteers, but real life and the overall complexity of modern email kills it every time. Running mailman3 is a nearly full time job to keep it working versus the lackadaisical mailman2 it replaced. Because it is trying to be both a webforum to catch that 'I don't want to use email' audience, a better archiver, and various other tooling, Things like system accounts, authentication, postgres databases, etc They are all needed to make it work. Outside of that DNS has many new fields which need to be implemented or added to deal with slightly conflicting standards which cause various sites to not accept email if they aren't implemented in their version. New fields are added and changed regularly which require dealing with people complaining that their email is now marked as SPAM, they aren't getting the email anymore, or that we have lost email because the queues on our systems overflowed due to various people subscribing to the SCM mailing list but having a quota too small. In any case, the issue is that there have not been for about 8 years to run this well. The task gets harder and harder over time due to complex DNS needs for email to work these days to just general time needed to clean up existing spam, deal with ham being marked as spam, etc. And when it comes down to 'does Infrastructure have time to keep builds, composes, and the 100 services running that are needed to do that' or 'does Infrastructure work on some part of an undocumented email system'.. the answer is always going to be get the daily builds out as developers complain a lot more about that than email. It is time to explore other options. One of them is the proposal that Matthew and I guess the Council have come up with. It is using a resource which is paid for, has an open source background, and is willing to make some changes to better accommodate other workflows. If people want something else they are going to need to come up with a proposal which does not include using existing burned out resources to accomplish it. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Interested in helping package unison
On Sat, Apr 22, 2023 at 03:02:51PM +0200, Jos de Kloe wrote: > There used to be a unison240 package, but it was orphaned over 2 years ago. > See: https://src.fedoraproject.org/rpms/unison240 You probably want to read back over emails on this list related to Unison, links here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DIGCQ5ON6DAGUJVHIS3RDRU3C6QGXIFM/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Interested in helping package unison
There used to be a unison240 package, but it was orphaned over 2 years ago. See: https://src.fedoraproject.org/rpms/unison240 On 4/22/23 09:59, Richard W.M. Jones wrote: On Fri, Apr 21, 2023 at 03:52:42PM -0600, Craig Christianson wrote: Hello, Unison is a tool I use all the time, and I would like to see it packaged for RPM systems. Is there something I can do to help? You will need to become a packager, if not already: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ Once there you can begin packaging Unison. Rich. ___ 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: Fedora magazine site down
There was a general outage at wordpress causing many sites hosted there to be offline. https://wpenginestatus.com/incidents/478228 I would like to thank the Red Hat Open Source Program Office (OSPO) for working on what the issue was, and answering questions in the Fedora Infrastructure ticket system. On Fri, 21 Apr 2023 at 23:09, Luna Jernberg wrote: > Seems to be up now again, atleast from my end here in Sweden with > Telia as an ISP > > On 4/21/23, Barry wrote: > > > > I see wordpress error page for https://fedoramagazine.org/ > > > > There has been a critical error on this website. > > > > Learn more about troubleshooting WordPress. > > > > Barry > > > > > > > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
Error with libheif package
Several users experience an issue with Fedora's `libheif` package, which can be easily reproduced: See https://discussion.fedoraproject.org/t/unknown-update-error-with-libheif/81302/6 With regards to our default dnf repositories: our package has weak dependencies that are not satisfied by our default repos, but by rpmfusion once enabled. The conflict itself is in the related rpmfusion packages . So once users have rpmfusion enabled, `dnf install/update libheif` ends up in a conflict because of `libheif-hevc` and `libheif-freeworld`. Neil, I guess this information is relevant for you? Not sure if you are also involved with the two related rpmfusion packages (?). Regards, Chris ___ 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
I'm relatively new on mailing lists but just wanted to give my opinion. With mailing lists one gets to choose the client to use, unlike with the web based forums where one is more or less limited to use a browser. The Discoure's mailing list functionality sounds interesting but how much it takes effort to configure and tune tags/categories to follow? Are the tags self explanatory or will there be brief info of which tag contains what? I would consider myself still as newcomer and I didn't find self-introduction and joining to a mailing list a problem. What comes to participation, this is my second post, so I haven't been taking part of conversation very actively. Switching to Discourse would not make me post more (unless there is magically more topics which I could participate in). Regards, Tomi Lähteenmäki ___ 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
Review swap Bottles dependencies
Hi, I'm looking for a review for a couple of Bottles dependencies. 1. python-fvs https://bugzilla.redhat.com/show_bug.cgi?id=2187061 2. vkbasalt-cli https://bugzilla.redhat.com/show_bug.cgi?id=2188653 Both are Python packages and I'll be happy to do reviews in return, with Python having my preference. Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee ___ 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 4/21/23 19:39, Jaroslav Prokop wrote: On 4/21/23 17:42, Matthew Miller wrote: On Fri, Apr 21, 2023 at 10:50:42AM +0200, Jarek Prokop wrote: also drives us towards more scattered communications. Our infamous mega-threads are not really effective for getting to community consensus, and tend to bring out the worst in us. Passionate people generate passionate discussion. The only thing you will gain by a forum is that at the point the message will not be deemed appropriate, it will probably be deleted or "beatified" by the mod team. The passion from our human nature will not go away with a platform change. That's true -- and I'm not looking to get rid of passion, or silence opinions. But when something is _really_ out of line (often written in the heat of the moment), it's better to have options to ... as you say, beautify* the conversation. That makes it better for other people participating, and better for the person who has a chance to make their point in a more constructive way. * also, to fix typos :) Oh, probably an important related feature I noticed after looking at Chris Adams' response, I had a small concern about people changing messages too radically, where the conversation will then lose meaning, the software actually supports history and colorful diffs. [snip] A discussion to a technical change, for me, will forever be in a ticket. No matter the "wider discussion platform" projects will always have bug trackers where one can create a ticket. Of course. That's not what I'm talking about. Consider for example this: https://pagure.io/fesco/issue/2817. That's not about the technical decision itself -- it's an branch of the conversation that should have been here. biased towards those for whom it is working just fine. But, core Fedora development discussion can’t be limited to that ever-shrinking group. Consider who isn’t here. The problems are real, and the trend isn’t in a good direction. But, is it shrinking due to a platform, or something other? I don't think Fedora contribution and activity overall are shrinking. And I'm quite convinced that the platform is part of it. It makes me want to try discourse out, not saying I'll stick around, I'm glad to hear that. 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 see something like "2 replies" under a particular post, you can click that and the view will be restricted to just those replies, which you can then follow further. 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? :) I think enhancing the visibility after I expand replies for the posts in the "thread" would be better. But also, yes — when something really diverges in Discourse, it should be a new topic. A moderator can move things after the fact (like I did with https://discussion.fedoraproject.org/t/getting-systemd-homed-working-properly-on-fedora-workstation/81004) but even better, when replying, you can create a linked topic. See https://discussion.fedoraproject.org/t/site-tip-create-linked-topics-for-deep-dives-or-tangents/34526 But I'd be happier if there was some tangible metric how to measure if we got more *related to the topic* engagement. I would hate to see 20 "+1" posts from "random" users counted towards "it is better now". That's reasonable. Do you have suggestions for a good metric? I'm afraid none that could be automated, but I am not one strong on metrics. I'll just throw out some ideas: 1. Number of unique contributors 2. How many unique posts these contributors interacted with 3. "quality" of the post. I think one could go by the length and verbosity of the post. E.g. "Yeah seems like a good change" is not as valuable as a deeper dive/analysis into a hypothetical problematic. (especially if we consider that the platform has +1 equivalents in reactions :)) 4. Number/frequency of interactions. Maybe a combination of 1. and 4. would have value. But we can worry about that a bit later than "right now". In Project Discussion, each different Fedora team can have its own tag, and you can subscribe to those that you’re interested in. Cross-posting is easy: tag a post with multiple teams. I'd be interested in having a kind of "crossroad sign", to direct me towards tags what I would care about from a packager perspective.
Re: Interested in helping package unison
On Fri, Apr 21, 2023 at 03:52:42PM -0600, Craig Christianson wrote: > Hello, > > Unison is a tool I use all the time, and I would like to see it > packaged for RPM systems. Is there something I can do to help? You will need to become a packager, if not already: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ Once there you can begin packaging Unison. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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
