-
Notifications
You must be signed in to change notification settings - Fork 400
Dracut development
Start by reading the Home.
See the github issue tracker for things which still need to be done and Hacking for some instructions on how to get started.
If you need help with your PR and move this project forward, here are the people you can contact:
Admins: Harald Hoyer, Jóhann B. Guðmundsson
Write access: Thomas Blume
Some general rules for writing modules
Expect compatibility preserved for
- documented dracut command line options
- documented kernel command line options
- documented dracut module names
- documented dracut module interface
Do not expect compatibility preserved for
- undocumented filenames and function names for dracut module implementations
- very old dependent binary versions (including udev and systemd)
Changes impacting compatibility are explained in commit messages and in NEWS.md. When possible dracut will follow a depreciation process, whereby for one releases (and one releases only) dracut will preserve compatibility to allow for migration (example: https://github.com/dracutdevs/dracut/pull/2104).
The compatibility promise is primary towards end users and not towards Linux distributions packaging dracut. Distribution packaging will need changes time-to-time between dracut releases (e.g. as files gets added and removed).
How to give feedback and review distribution specific changes ?
Most people using Dracut has some sort of preference or biast towards a specific Linux distribution. It is common for a contributor to only test a PR on one Linux distribution and not consider other distributions.
Reviewers and maintainers are expected to challenge PR's that are not distribution agonistic. Expect longer discussions on those PRs. This however does not mean that distribution specific PRs are automatically rejected. The project has a long history of maintaining modules for specific distributions, architectures, package managers and HW configurations.
Do
-
Consider the benefit of the PR even if the PR is distribution specific ! Would the PR lead to a lot more people using Dracut/dracut module or the PR just benefits a handful of people? Remind yourself during the review that more Dracut users will lead to eventually more Dracut testing and more Dracut PRs and higher quality software for all Linux distributions - including your preferred distribution. This happens more often than you think and it tends to be underestimated during reviews.
-
Consider the cost of the PR. Is the PR in an isolated dracut module that can be simply removed later if maintenance is a problem or the PR is adding changes in core components all over the place that is not easy to remove later ? Is the code from the PR covered by tests that would significantly reduce the maintenance cost ? Can the PR changed in a way that reduces cost even if it stays distribution specific ?
Don't
-
No need to guess or assume things that are outside of the scope of a given PR under review. The job is not to predict the future beyond the next release. Consider if the PR would be useful for the current release or not. Comments like "If we allow this PR, that when will we stop including similar PRs" or "we do not want this PR because of some future plans that are not yet agreed by the project" are not specific and confusing and just invites further comments that are not in scope for the PR. We have a process where we consider each PR review in isolation. If the PR improves code that is currently in the upstream tree, it should be strongly considered.
-
Do not consider if the PR is useful for you personally or not. Spend time understand the benefit and the cost. You are reviewing a PR that somebody spend time to prepare for the project that is over 10 years old used by millions of users with thousands of commits from about 300 contributors. Try to make a decision based on data and not based on emotions. If you need more data, just ask.
Dependencies for the generated initramfs:
- glibc or musl
- shell (bash and/or dash). Some features are only supported with bash.
- udev. Forks of systemd's udev and related tools are unsupported.
- switch_root, mount, blkid, kmod
This is how you can have CI environment locally. Current directory should be at your local dracut directory. The following command executes tests 04 and 01 inside a fedora container (yes, the 0 is significant).
$ cd <DRACUT_SOURCE>
$ docker run -ti --rm --privileged -v /dev:/dev -v $PWD:/w ghcr.io/dracutdevs/fedora /w/tools/test-github.sh w "04,01"
- arch - upstream regressions (e.g. systemd) usually show up here first
- debian - deb packages, older versions of software
- fedora - most complete (e.g. systemd-networkd is only installed here, some tests only run on this container)
- gentoo - musl and openrc only available on this container
- opensuse
- ubuntu - deb packages, usually newer versions of software than debian
- bash - v5.1+
- udev, systemd - v252+
- glibc - v2.36+
- musl - v1.2.3+
- linux-kernel - v6.1+
https://github.com/dracutdevs/dracut/actions/workflows/manualtest.yml