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.

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. Short term, we are just going to manually sign them, but work on signed repodata or better ideas welcome here.

• 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? This work is ongoing now.

• 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). Create updates.img to allow fedup to upgrade to rawhide?

• <stike>add more 'best practices' and tips for rawhide users.</stike>

• • run yum-plugin-local to allow for downgrades</stike>

• • 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?

• No broken deps in rawhide ever. Check builds to see if they break deps, and block them from entering rawhide target. Put in a separate build target, where downsteam deps can be rebuilt, then atomically merge all builds into rawhide. User:Berrange

• <stike>Make it easier to upgrade to or start running rawhide. Perhaps a recommended way thats tested periodically at least?

(Feel free to add additional ideas here, or comment on the above ones, just add your User:Username after comments or new adds)

Additional Info

http://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

https://fedoraproject.org/wiki/Releases/Rawhide