From Fedora Project Wiki

(add some more things.)
(add idea about automatic rebuild)
Line 42: Line 42:


* Make things more clear to consumers of rawhide who it's for. (propose changes to rawhide page)
* 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.


= Additional Info =
= Additional Info =

Revision as of 17:49, 19 January 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.
  • 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.
  • 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.

Additional Info

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

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