On Wed, Jan 20, 2010 at 09:29:03AM +0100, Michael Schwendt wrote: > On Wed, 20 Jan 2010 03:35:33 +0100, Ralf wrote: > > > >> IMO, somebody at Fedora's Release Management hass not done his > > >> homework. > > > > > > See Dave Airlie's post to devel "libdrm vs mesa updates - update group > > > for bodhi?" > > > > That's not my point: > > > > My point is: Why are package which apparently break package dependencies > > being pushed to public repos rsp. why does rel-eng not catch them before > > they break public repos? > > Because releng doesn't run any broken deps checks yet. Also, the compose > process they have come up with after the Fedora Extras era has required > many hours for each push, so a brute-force "build repo, check repoclosure, > pull packages, rebuild repo, check repoclosure, …" cycle would not be > feasible and would not be convenient either. [Dunno whether anyone has > spent time on playing with a new tool yet that would compare packages with > target repos and look for dependency breakage, conflicts and other problems.] Yes, the QA team has been working on this -- I asked them about this when I found out about the broken dep problem with mesa-libGL/libdrm. Neither would the "repoclosure after each build" work, because a repoclosure is too time/CPU-consuming. So they're working on an incremental system that would check only the required chain, and (I'm assuming, don't quote me) the pieces that have changed. The algorithm they're working on still needs some further tuning but they're making progress. More contribution is welcome I believe; Will Woods is the person to talk to if anyone is interested in helping out. > > I.e. I am not pointing at the "packager/package maintainer", but at > > Fedora's release managers/Fedora's release engineering. > > You can still point a finger at the mesa/libdrm package maintainer, too, > though. Not grouping the builds and pushing them in a single update > request is a mistake.... [...snip...] Yes, I suggested to Will that as they're working through establishing this checking process, it ought to encourage correct behaviors such as grouping builds. So if people want to help or discuss the ins and outs of this process, you probably want to take that discussion to the QA team's test list: https://admin.fedoraproject.org/mailman/listinfo/test -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines