On Wed, Jun 13, 2007 at 03:20:33PM +0100, David Woodhouse wrote: > On Wed, 2007-06-13 at 10:11 -0400, Daniel Veillard wrote: > > yeah yeah, and s390x pointed out a bug in libxml2 about some obscure > > aliasing problem. But in general going though that wasn't very fun. > > Yeah, finding bugs isn't fun. Let's never increase our test coverage. haha, nice rethoric. The problem is *when* do you test ? Compiling after release time on the weird platforms is nearly the worst time possible to run those checks. That means the code is already upstream, you're usually under tight timing constraints for pushing, and blocking your build because say Ekiga doesn't built on s390 puts the packager in the most awkward position possible. He gets to try to fix a bug raised on an architecture he has no knowledge of, without help from the upstream community, blocking everything else and then forcing him alone to come with a "quick fix". A sure recipe for disasters ... Suggesting I'm against testing software portability is a good joke, thank you, I'm sure the whole libxml2 community will have a laugh if you forward it in the proper place :-) Now to get back to serious stuff, yes we cleaned up most of the packages which constituted Core, but we are gonna regress now because compilation on the 'odd' platforms will now occur even more asynchronously when the Red Hat employees will start to recompile for RHEL release, possibly one year after the software has been pushed out. The later you catch stuff the more expensive it is, I doubt anybody will disagree, right ? We don't want to have those weird platform in the way of Fedora apparently (I don't know the exact reasons). Can we have them in parallel ? I'm thinking of asynchronous builds of what constitutes Fedora done on those box and error reports being raised to the packager or as bugzilla entries if they fail. That would be one start. But blocking the packager synchronously at build time is really not proper IMHO. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
