On Mon, 11 Mar 2013 12:50:53 -0400 (EDT) Kamil Paral <kparal@xxxxxxxxxx> wrote: > > - bugs that break the rawhide buildroot. In practice these are > > usually > > noticed pretty quickly and the offending build is just untagged > > until > > it can be fixed, but there could be cases where the fix is more > > complex and has a bug associated with it. > > For those of us who are not skilled in building a release, what does > this exactly mean? I can imagine bugs that prevent compose (no > package repo created), but this one could deserve a closer > explanation. The rawhide compose script ( http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide ) does: mock -r $MOCKCONFIG --uniqueext=$DATE --init mock -r $MOCKCONFIG --uniqueext=$DATE --no-clean --install koji yum createrepo cvs make intltool findutils mash yum-utils rsync repoview hardlink So, I was thinking this was those packages and their deps. If those have broken dependencies, don't install or don't work, there's no rawhide compose until they are fixed. > > - bugs that cause a large number of rawhide systems to be > > unbootable. This would be things like dracut or kernel or glibc or > > systemd issues > > that cause most rawhide installs to fail to boot. > > What about broken gdm, does it fall into the category? Should > "critical path packages" be also covered by this tracker bug? > (Firefox broken, pulseaudio broken, gnome-terminal broken, yum > broken, ...) Well, we could look at adding critpath, but I think that could get us into more hazy territory, and some subjective issues around 'broken'. Especially since rawhide packages can change interfaces, and something behaving differently one person might call 'broken'. Is there any way we could describe this as a more easy to understand criteria? kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
