On Thu, 2011-11-17 at 15:03 -0800, Brendan Conoboy wrote: > On 11/17/2011 11:04 AM, Chris Tyler wrote: > > I agree with going with what we've currently got package-wise. But > > saying "we should start building today" or "get Koji running...tomorrow" > > is missing the point. :) I'm not so sure. I think the goal should be to get to rawhide as quickly as possible because it makes all of these problems go away - no rebuilding retrospectively, not being treated quite so much as a secondary, and so on (then we push for primary). Given that that is our general ambition, we should work backward and try to get to that point as quickly as we can without being too hackish in our approach. > > We're ready to go the moment we have finished these tasks: > > - the gcc/glibc issues are resolved Let's split these in two: 1). gcc. Having seen some of the discussion here with Jakub, etc. it's clear that the Fedora maintainers aren't going to accept this latest volatile bitfields patch unless it's in the upstream 4.6 branch (it is in trunk right now). So there are two upstreams to work with - Fedora, and GCC. We can try to pursue this, but it is not a quick fix (we're looking at several weeks to turn it around). At the same time, this stuff is resolved in rawhide (and I think F16). It would be more expedient to block updates to gcc being pulled in automatically (which won't happen at this stage anyway) and either in parallel fix this or undertake to keep a separate gcc. Really, by the time we release F15 we'll have only 5 months of time when there would be updates anyway. 2). glibc. Seems there's a backport that could perhaps be upstreamed, and a Java fix that we will need. Again, I favor parallelization. We build now and try to find a solution that involves either getting this into upstream Fedora 15 PA or finding an alternative. I don't see a reason not to build this now though. > > - we've pruned the package sets back to the same core I think this is straightforward. We include in the repos only the build requirements to build a buildroot and start with that. Do some closure tests on that set and make sure the same packages exist for v5 and v7. I suspect someone could turn that around tomorrow. > > - every change/patch in those package sets has been upstreamed I was thinking that way, but now I think that is a parallel activity. I am all for getting stuff upstreamed, and it will be especially important in the coming months, but I think that doesn't need to gate the initial build. Packages can keep an armX suffix in the initial build, then for the few dozen (after cutting down the initial build set) that need to be upstreamed, there will be a higher NVR from upstream soon anyway that can be rebuilt for both arches with the upstream version. IOW I think the initial build should proceed now, but that we should not begin building updates or pulling further bits from upstream until we have gotten the rest of these deltas resolved. Since the upstream version will bump once they're fixed, NVRs are preserved, everything will work. The only critical thing is that we didn't bump the R in a non-forward thinking fashion, which is why the use of the .armX. > > - the hub and builders have been successfully set up and tested with > > patched koji/rpm/yum etc. I think that should be fairly straightforward now. Dennis has patches that he has tested in a staging Koji setup so they ought to be working. > > Work on all these pieces is proceeding in parallel (assuming that > > someone's on the gcc/glibc piece (who?)). We're not blocking on any one > > piece, but we have to finish these four before hitting 'Go'. Respectfully, I disagree that we need to block on all of them. I think we can begin building, and in parallel upstream whatever can be upstreamed, ensuring that for the one or two possible exceptions we have a plan for F16/F17 along the lines of "in gcc trunk", etc. > The final patch for gcc, for instance, may never make it into F15. Even > the armv7hl spec file changes we pushed upstream are only in .fc16 koji > builds at this point. If these changes are in FC16 or rawhide but not > F15, isn't that good enough? Why not build packages in parallel too? Well, Chris is naturally going to be concerned about building updates, and there is a sense of more correctness in blocking, however I think: 1). We need to resolve a few more things before building updates, but we buy time to do that and win now by building sooner while we handle that. 2). We are past the time when we should aim for the most complete F15 release. F13 was a wonderful example of a quality ARM release that the Seneca team (in particular here) should be proud of. BUT there is an opportunity here to leave all of these problems in the dust if we can just bring F15 to a good enough close and get to rawhide soon. I know, I sound pushy. I don't mean to. I'm not calling for the rocket to be launched for a manned flight before it's ready, I'm saying F15 is the test rocket that's going to get us to the moon landing in F17. Jon. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
