[rawhide] ideas to improve rawhide

Kevin Fenzi kevin at scrye.com
Wed Jan 23 18:01:50 UTC 2013


On Wed, 23 Jan 2013 11:43:00 -0600
Bruno Wolff III <bruno at wolff.to> wrote:

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130123/c9622a7e/attachment-0001.sig>


More information about the devel mailing list