Rawhide improvement project 2013
Introduction and goals
Althought the stability and day to day usability of rawhide has improved over recent years, there is still a perception that it's unusable for day to day use or non mission critical desktops and servers. This project seeks to make rawhide more stable and usable in an effort to gain more testing, as well as to satisfy proponents of rolling releases (rawhide is always rolling forward). This page is a place to collect such ideas and track their implementation.
- Don't want to make things more difficult for maintainers.
- Don't want to divide resources, we should instead increase signal on devel and test lists and irc channels.
This is just a bare container for ideas, will be discussed on the list and fleshed out first.
- Have a group of rawhide running folks that can notify maintainers who don't follow the rules (don't announce abi breaks, add builds that are completely broken, buildroot breaks, etc).
- A rawhide-broken tracker bug? This could have bugs that are serious issues with rawhide added to it for more attention, etc.
- Some way to sign rawhide packages? Auto sign patch isn't upstream, manual signing would be behind, need more ideas.
- More autoqa? "hold" builds with broken deps or otherwise failing?
- Some way to more easily roll back packages? Keeping 2 in repo would bloat things, perhaps have another repo for yesterdays rawhide? Some plugin to pull from koji for downgrades?
- Could we dial back on debug options on the kernel? Make the debug build usable for day to day?
- Some kind of indicator when major parts of rawhide are not functioning? Webpage or blog or the like.
- After branching, identify components that don't build for rawhide and cause issues, and offer to help maintain them, and/or not allow inheritence.
- make rawhide installable again? (This would allow more installer testing).
- add more 'best practices' and tips for rawhide users
- run yum-plugin-local to allow for downgrades