English Burmese
Other than features, we also need to:
write tests to significantly simplify contribution
do performance optimizations for the service to scale well
explore the use of CI and Rawhide Gating
Being able to see what's going on is a prerequisite of implementing any changes. Seeing all the relevant opportunities helps us to focus on the ones having the most impact, and a transparent tracking helps us prove the usefulnes of our work, and to further focus on the most impactful activities.
**Minimize** the installation size of the use cases by optimizing RPM dependencies, features, software architecture, and other factors. Specifically, look for:
Unnecessary RPM dependencies (although there probably won't be many)
Multiple implementations of the same functionality required by various packages — try to make them use the same one
Context-specific requirements — such as requiring Systemd on traditional deployments being fine vs. requiring it in containers means significant size increases. Leverage weak dependencies in those cases (that might require code changes).
Dependnecies on large things while only using a fraction of the functionality — such as requiring the whole Perl stack to run a single script — such script can be rewritten to Python which is everywhere mostly because of DNF
**Engage with upstream developers** regarding bigger changes in packaging and architecture. An example is Systemd and splitting the __systemd-sysuser__ package.
**Implement process and policy changes** reflecting bigger, more general changes. Again, a good example is using Systemd in containers, or the general issue of creating users in containers.
**Provide guidance** for the Fedora community in form of blog posts, videos, and conference talks. Even though we might have guidelines and policies in place, spreading the word is always important.
Resources and Inputs
Cloud resources to prototype services. We are not going to change the existing Fedora infrastructure in any way before whatever we develop proves useful and worth the hustle of stabilization and changing production.
No existing Fedora Infra or Release Engineering resources are needed at the moment. However, we might need help with setting up (or getting access to) the cloud resources.
Active support from our maintainers, the FPC, and other community members is definitely needed. This is obviously not something we can "request", but it's still a necessary input.
Guiding Principles
**Usefulness over size**: There is a balance between the usefulness and size. We take that in mind and will not implement drastic changes that would prevent our users from using Fedora. However, nothing prevents us from producing additional very specific and mininal artifacts.
**Using RPM**: We're doing this with RPM. We're not achieving minimization by deleting files after installation. This might be obvious, but still worth mentioning.