On Wed, Jan 23, 2013 at 09:55:07 -0700,
  Kevin Fenzi <ke...@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to