[rawhide] ideas to improve rawhide

[Bruno Wolff III]

On Wed, Jan 23, 2013 at 09:55:07 -0700,
   Kevin Fenzi <kevin at scrye.com> wrote:
>
>So, I've been collecting ideas on how to improve things in rawhide and
>have made a wiki page for these ideas.
>
>https://fedoraproject.org/wiki/Rawhide_improvement_project_2013

Would the rawhide tracker bug be for rawhide users? I'm guessing the intent 
would be to make finding out if someone else already filed a bug for a 
rawhide issue one is experiencing a bit easier?

Manually signing rawhide builds seems to conflict with your anti-goals 
of not taking away resources from other things. It's probably better to 
just wait for auto-signing.

Holding builds with broken deps isn't going to help testing in a lot of 
cases. Sometimes dependent packages take a long time to get rebuilt. For 
myself I usually remove the packages blocking updates in order to be able to 
use the new packages. I think a better solution here is to have more 
proven packagers jump in and do rebuilds for soname bumps. (Unless a package 
has changes in master that haven't been used for a build yet, this is pretty 
safe. Though this might run up against people doing builds in branched and 
not rawhide.)

The anaconda guys have not been big fans of making rawhide installable since 
it tends to generate bug reports for things that aren't finished yet. (That 
they already know about.) It may be that install testing is best done 
with branched.

I find that yum plugin local tends to suck up a lot of space for little 
benefit. I tend to want a few specific packages to either downgrade or 
to get fixes that won't show up until the next day. I grab these from 
koji and add them to my own local repos.

I'd like to see a stronger push to have packagers start work in master, 
not branched. Inheritance ends up leaving stuff broken longer in rawhide 
and doesn't test building packages in rawhide, so that problems go 
unnoticed.

The one day delay may not work that well. If no one is trying the latest 
kernel, dracut or systemd, then people are still going to get hit, just 
one day later. Still it would be nice to be able to fix seriously broken 
stuff in less than one day in a way that's easy for people to use, rather 
than everyone doing their own manual fix.