Re: Updating Taskwarrior to v3
As a tangent on this thread, it would be cool if there were a mechanism in dnf to tell users when an upgrade needs special attention/instructions. Another example like this is postgresql updates, which also require manual intervention. -- ___ 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 7/7/23 19:59, Demi Marie Obenour wrote: That is not consent. The GDPR explicitly states that consent must be opt-IN. I agree. I think it is important to make it possible for a user to ask for the data collected from their machine to be deleted in the event they mistakenly submitted data, or changed their mind. ___ 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/26/23 08:42, Kevin Kofler via devel wrote: As I see it, the main roadblocks for new packagers are: * accepting the FPCA, * getting sponsored, * learning the Packaging Guidelines, and * getting their package(s) through review, and that last point can be a roadblock even for existing packagers (because we do not trust even experienced provenpackagers and/or packager sponsors to review their own packages). I agree with Kevin on these being much larger roadblocks than e-mail vs. forums. I also contribute to another distribution, and they accept pull requests on GitHub with the standard git Signed-Off-By tag (i.e., nothing like the FPCA to agree to, no sponsorship needed, really no commitment of any kind needed - just send a PR and wait for someone to review/merge it. It's super easy, barely an inconvenience!) For those who aren't keen on GitHub, the same distro also accepts patches to their mailing list as long as you do the same Signed-Off-By tag. I've found contributing there to be quite easy. I harbor doubt that changing to a web forum will make a notable difference in technical contributions to this project (the sorts of things that this list is about). I don't carry that doubt about many parts of the Fedora community, so I mean here to focus specifically on what this specific list, devel, is usually about. I do think we can do a lot to lower that barrier to entry for new comers regarding the things Kevin is talking about, though I suppose the FPCA thing can only be relaxed with lawyer permission. I think it's possible to mirror to GitHub and require FPCA (if we really must have it) - I've seen a few projects on GitHub that had a mechanism to enforce agreeing to a document before they would accept PRs. Loads of people have a GitHub account already and it would be much easier for them than having a FAS account (the other distro I contribute to doesn't require contributors to have an account, though I do). I think reviewing code is a healthy practice. One thing I've always thought was a little weird is that we only require new packages to be reviewed, but after that the packager can do anything. I guess I've always assumed that this was more about getting a second person to agree to the license/patent implications of the package, and probably not the code itself (since that will change over time without further review). I guess if that's why it kinda makes sense. ___ 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/26/23 11:25, Matthew Miller wrote: Use j/k to scroll up and down (ah, vi, your legacy will live forever) According to Wikipedia, it's actually the ADM-3A: https://en.wikipedia.org/wiki/ADM-3A#Legacy I recently learned this, and find it fascinating ☺ ___ 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 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. ___ 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: nspawn for rawhide?
On Thu, 2022-08-18 at 14:01 -0700, Kevin Fenzi wrote: > Thoughts? ♥ nspawn ♥ signature.asc Description: This is a digitally signed message part ___ 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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Thu, 2022-04-07 at 17:02 -0400, Simo Sorce wrote: > > I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"? > > For What My Opinion Is Worth :-) I also hadn't seen this acronym, but I was hoping it was going to be some kind of cipher since Simo works on the crypto team ☺ signature.asc Description: This is a digitally signed message part ___ 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: Fedora Source-git SIG report #1 (June 2021)
On Wed, 2021-06-30 at 14:31 +0200, Tomas Tomecek wrote: > After reading your explanation of how gentoo does packaging, it > indeed makes a lot of sense and feels like that most of the > concerns I pointed out have solutions or could be mitigated. > > The biggest problem I personally see is the effort which would be > needed to pull this off: it would take years to accomplish, a ton of > teams would be involved and all the maintainers would need to > cooperate - and then we'd need to do the same thing for CentOS Stream > and RHEL. > > Such a change to the development workflow would be massive and the > level of coordination would be immense. That's all I can say. I agree, it would be a lot to change. > > Looks like the gentoo-bot is a critical piece of the development > process so that people are able to progress with their contributions > efficiently. It certainly does feel pretty helpful. Even if we don't go for a monorepo here, one could imagine a bot like that being useful here too. > > Thanks Randy for such a great write-up. Now that I think about it, > the monorepo proposal is orthogonal to the source-git proposal as the > two workflows serve different purposes: one is meant for development > (source-git: write a patch), the other one for integration into the > operating system (tinker with a spec file or the build system). Yeah I do think they are orthogonal concerns. Enjoy your weekend Tomas (and everyone!) signature.asc Description: This is a digitally signed message part ___ 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: Fedora Source-git SIG report #1 (June 2021)
On Wed, 2021-06-30 at 01:01 +, Randy Barlow via devel wrote: > An example of this is gstreamer - in Gentoo I just have > gstreamer installed, and the various plugin packs like good bad and > ugly are just USE variables on that one package. Ooops, I was wrong on this example. They do package good, bad, ugly as separate packages. signature.asc Description: This is a digitally signed message part ___ 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: Fedora Source-git SIG report #1 (June 2021)
On Tue, 2021-06-29 at 15:36 +0200, Tomas Tomecek wrote: > > On the "uni-repo" counter proposal: there's a bunch of real-world > > examples here of distributions using this successfully: > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow Hey Tomas! As Colin noted above, Gentoo uses a single repo (well, technically, they also have overlays, but the main distro is just one git repo is what I mean…) I'll add some comments to your thoughts below: > * Can you imagine maintaining Fedora's 30k+ packages in a single repo? > Without some git-fetch magic it would be unbearable to perform a git-pull. Gentoo has 19,302 packages according to their packages web app[0]. Some Gentoo packages map to more than one Fedora package, since Gentoo has slots and uses USE flags. For example, there's just one package called "python", but you can get various Python versions from the same name (vs how we have a separate package for each Python version in Fedora). Programs with lots of plugins end up being one package that has USE flags for the plugins, where in Fedora the plugins might be packages separately. An example of this is gstreamer - in Gentoo I just have gstreamer installed, and the various plugin packs like good bad and ugly are just USE variables on that one package. I mention these differences to say that it's probably fair enough to compare the set to Fedora's 30k. I will say that a git pull does take some time, especially if you haven't run it very recently. It's not unusable, but you do notice it for sure. I just ran a quick test on two different systems with wildly different results: * On a system with an ssd I hadn't pulled for two days, and a git pull took 0m3.357s. * On a system with a spinny disk I hadn't pulled since January 17, and a git pull took 1m27.878s. I'd say that this is probably close to a "worst case" scenario, except that I do have a 200 Mbps internet connection. Most of the time was spent doing stuff with the disk and not on network. I could imagine a slow network making this even longer. I would say this is the top downside to the monorepo approach that I personally experience. But I also tend to use the SSD system for this, and also tend to pull often enough that it's not a big deal. > * Git history would be immensely bloated (though `git log $path` > would work well). Yeah I always just use git log $path myself, and it works fine. I also think it's kinda cool that I can tail a single git log and see what people have been up to across the project, but we can also do that with the message broker in Fedora. > * On the other hand, I like that changes could be done "atomically" > in a single commit, even for multiple packages. I *love* this, and to me it's the best thing about the design. If you have a change to one package that requires a corresponding change in others, you just do it in a single commit. In Fedora we don't have an easy automatic process for this. We *could* build one, but it would be harder to do. With a monorepo, it's just something you get for free. > * How would CI function? Due to the atomic commit, I'd say CI could function better because you know what changes need to be tested together. Gentoo doesn't have per-package CI that I'm aware of, but they do have general checks that they do on all packages. They've got a QA bot that check PRs on GitHub and marks them as pass/fail. > * Where and how would tests be stored? As said, I don't think Gentoo does this, but I could imagine having a tests/ subfolder in the package's folder, not too different from what we do now. > * As Neal pointed out, ACL mechanics would need to be thought > through. GitHub does have a codeowners feature, which I think could be adapted for this purpose. One could imagine a server-side git push hook that checks an ACL rule list against the paths that were altered. I think such a thing could probably be implemented in not GitHub as well. I wouldn't say it's trivial to do so, but not extremely difficult either. > * src.fp.o and koji would need to be updated, significantly. Agreed. > * How would contributions be handled? It would be hard to detect > stalled PRs, maintainers would be swarmed with changes not related to > their packages. Here's an example of a Gentoo PR I worked on recently: https://github.com/gentoo/gentoo/pull/20975 Note that there are two bots that have commented on it. The interesting one for this question is gentoo-bot - it came and marked the PR with some metadata, helpful links into the bug tracker, CoC, and other stuff, and most usefully, labeled the PR with some special labels. If Fedora had such a bot you could imagine it doing things like assigning it to the right person (or otherwise notifying them), pinging long-open PRs, or other things like that. The other bot on that PR is the Gentoo QA bot, and it does some basic checks on your
