On Wed, 23 Jan 2013 11:43:00 -0600 Bruno Wolff III bruno@wolff.to wrote:
On Wed, Jan 23, 2013 at 09:55:07 -0700, Kevin Fenzi kevin@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?
Well, it's open to discussion. ;)
I could see it being useful for:
- users to watch and see when new bugs are added to it that affect a significant number of rawhide users. If you see this before you update to the broken package you could work around or exclude it until it's finished. ie, increase awareness.
- It could also reduce duplicates.
- Might help maintainers watch for any kinds of 'fallout' on something they landed that may not at first be filed against their package.
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.
Well, it's easy to do and it only would affect Dennis and Me, so I think it's worth doing since we can do it almost immediately.
It's pretty unclear when we might have an acceptable auto-signing setup.
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.)
well, sure, but sometimes more than a rebuild is needed.
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.
Perhaps. I would love to have them chime in and see if this has changed any. I think it would be useful to have such testing before 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.
Yeah, I'm afraid I agree.
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.
yep. This is one reason I would prefer to just drop the inheritance.
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.
There would need to be a way to choose between 'one day delay' and 'today's now'. So, you would get the early adopters testing and fixing things so the people one day behind would get the fix.
For that matter, we could start doing 2 rawhide composes a day, spreading our the changes and allowing fixes in faster.
kevin