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.
Anti-goals
- 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.
ideas container
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? Have people use yum-plugin-local more?
- 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.
- Dashboard suggested in https://bugzilla.redhat.com/show_bug.cgi?id=204584
- 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
- more snapshot usage to roll back things.
- Make things more clear to maintainers their responsibilities around rawhide. (announce abi changes, side tags for large, long rebuilds, not pushing things that are broken, etc)(per cycle reminder to devel-announce? notes to new maintainers?)
- Make things more clear to consumers of rawhide who it's for. (propose changes to rawhide page)
- Automatic rebuilds when broken deps land. Just rebuild automatically.
- Some day to update only after packages are in for a day, since most problems are fixed after a day, updating a day lag would avoid many of these. Yum plugin?
Additional Info
http://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master