On 09/21/2011 04:43 PM, Nils Philippsen wrote: > On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote: >> On 09/21/2011 01:25 PM, Nils Philippsen wrote: >>> On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: >>>> On 09/20/2011 05:52 PM, Nils Philippsen wrote: >>>>> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: >>>> >>>>>> When you have a closer look, you'll notice that such "mass rebuilts" >>>>>> were being delayed by QA's "delay queue" and now are stuck. >>>>> >>>>> I didn't want to (re)start that particular discussion ;-). >>>> > >>>>> We need some guidelines who should drive rebuilds in such a situation, >>>>> regardless of whether it happens in Rawhide or Branched or wherever. >>>> a) These situation can only happen in release branches. >>> >>> Uhm, no. A library SONAME bump can happen in Rawhide as well as in >>> branches and if dependent packages don't get built with the new version, >>> things are broken. >> Right. They break in rawhide, where issues are inevitable and can be >> addressed within short terms because maintainers are not being forced to >> play "10 days per package update" "you wait for me/I wait for you" delay >> ping-pong. > > And that's always fine and dandy if these issues are resolved in a > reasonable amount of time. Right now Rawhide has packages with > dependencies broken since pre-F15. This isn't acceptable.
Agreed - If so, these need to be addressed. IMO, if packagers and/or proven packagers are not able to fix these in "reasonable time", I'd consider it to be QA's job to take care about these. As experience as a proven packager, who did try to address such cases in the past tells, such cases typically originate from a) packagers not being sufficently skilled to fix such breakages and them not asking for assitance. b) packagers having gone AWOL or being unreachable c) packages being sufficiently incompatible to an upgrade that they better should be removed/retired. Wrt. a) experience tells, some packagers are hesitant to ask for assitance and prefer to "sit out the issue", until some proven packager or upstream takes action. Wrt. the packages I had stepped in, case b) was fairly common. IMO the cause is Fedora lacking a spirit of "teaming up". Wrt. c), here the issue seems to be packagers being hesitant to "draw a cut" and to retire a package. Surprisingly, when directly contacting maintainers of such packages, they often agree to such retirement. >>> Waiting for dependent components to be built at their >>> maintainers leisure or whenever a mass rebuild comes around isn't a >>> solution, not if we want to have a "more stable Rawhide". >> >> To we want this? I don't. To me, rawhide is the "big package dumping >> ground" for the bleading edge". Certainly, it should be as little broken >> as possible, but "its brokenness" is part of its working principle and >> inevitable to me. That said, I find a stable "rawhide" to be >> nonrealisting and inapplicable. > > You're twisting my words a bit. I wasn't opting for a stable, but a more > stable release. If somebody wants to test something in Rawhide they > shouldn't have to debug other parts of the distribution. This means that > changes should be done with enough circumspection that breakage is > reduced to a minimum. People who actually run Rawhide (and I know their > number is low) would thank us for that. Well, what am I supposed to say? Anybody would be grateful for less bugs and breakage, but ... on rawhide breakage is simply inevitable. > Right now this is not the case: a substantial number of components is > broken due to unsatisfied dependencies alone, meaning that everybody who > wants to test Rawhide in conjunction with anything on that list is > simply out of luck right now. That's one view. From a packager's view, whenever something changes incompatibly, no matter how careful and speedy the packager tries to be, there always be situations when something breaks. Typical case are: The packager who is pushing an incompatible upgrade misses a "to be rebuild package", the packager doesn't have sufficient privileges to rebuild a package in need of a rebuilt or the upgrade renders a package unbuildable ... IMO, the last on this list is the critical case, which is causing rawhide users to complain. > I admit that the impact of being broken is > not the same for every component in the distribution: some stuff more on > the fringe is sufficiently isolated that it will only affect few testers > if it doesn't work (ideally the ones fixing the breakage), so it won't > hurt many if these are broken for a longer time, but other components > are central enough that they can't afford that luxury. No disagreement. > It would certainly help here if buildroots could be created for Rawhide > so that breakage can be resolved in isolation there. I am using local mock environments which inherit from "upstream" (== Fedora), as a band-aid to identify potential breakage and to keep impact of incompatible upgrades low. This often works, but not always. > In this case they'd > need to be created before the first package is built however, so it > doesn't break unrelated builds. This is because we don't file Bodhi > updates for Rawhide packages (nobody in their right mind would want > that). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
