On Tue, 2006-02-14 at 12:43 +0100, Michael Schwendt wrote: > On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > > > 1) A forced rebuild, just to check whether a package still builds, is > > > something that can be done by the maintainer _locally_ using mock or with > > > FC5 Test 3. > > > > You forget that we have some packagers that live in parts of the world > > where internet bandwidth is costly. I suspect that each rebuild for > > devel with mock will download 300 - 750 MByte. To much for those > > packagers afaics. > > That's just another exception. As is a package which doesn't need a > rebuild. > > A packager who's not running Rawhide--or at least one late test > release--cannot test the binaries at all prior to FC5 being > published. Let me pull you this tooth - In the vast majority of all cases, you don't need a particular OS/version of an OS to test whether a package is functional, because most packages' functionality is independent of any OS. Therefore testing update/upgrade-packages on such similar OSes (e.g FC4 vs. FC5) will be enough in many cases. Also you can't expect to a package that is known to work on one architecture to work on others, and require all maintainers to test them on all architectures - That would be irrational nonsense. > There are > packages in the repository which are not orphaned, which have been > rebuilt, but which don't work or which hardly work well. File bugs to bugzilla, that's what bugzilla is for and what rawhide/development is for: Testing SW and identifying bugs! > The information > we are seeking is: What changes in Core/GCC/ABI/BuildRequirements/DepChains > _require_ a rebuild of a package in Extras? Such cases require a rebuild. They should be detected automatically and should be triggered automatically. If this isn't possible, this has to be done manually by a centralized instance, either an individual or "rebuild task force". > For instance, if I'm told that > the updated compiler gives significant performance improvements or adds > more security features or reduces the risks of miscompilation this > would be reason to rebuild my binaries although everything seems to work > fine in current Rawhide. This would not justify a mass rebuild because this doesn't qualify a package as non-functional. A gradual rebuild would be sufficient. > Or if I see that some of the build requirements > I depend on have changed, I'm interested in how this might affect my own > packages at build-time and at run-time. This would qualify as a packaging bug, should be bugzilla'ed and be addressed by normal bugfixing > So, to decide when something needs > a rebuild, I need to monitor dependencies. Right, more aggressively: changing deps should trigger rebuilds. > Similarly, before I perform an > upgrade to one of my packages, I need to watch and test carefully whether > anybody else might be affected by the upgrade in bad ways. That's the > whole big show that's supposed to just work within Fedora Extras all the > time. API/ABI breakage, e.g. It is mandatory that I perform local > test-builds of packages which depend on my packages. Not necessarily. If a packages ABI/API don't change upon upgrades/updates, there should not be any need to rebuild a package. > Where not possible > due to lack of bandwidth, more coordination is necessary among the package > maintainers. I cannot simply commit my upgrade and then be confronted with > the wreckage. But that's what FESCO currently is doing: You are producing wreckage. > > And even if that wasn't a problem -- how do we make sure that people > > really tried if a package still builds? > > Do we care? I'm mainly interested in whether a binary package _works_ Exactly. As long as a package can be correctly installed and seems to work, there is no need for immediate action. If it can't be rebuild, ... bugzilla ... > > And we have a lot of not that important packages in the tree now, some > > of them are rarely updated upstream (take tiobench for example). We > > might never notice if that package is orphaned if we always do a > > script-mass-rebuild... > > Yes, a scripted mass-rebuild introduces a false sense of activity. Who > skims over the build logs to watch out for failed configure tests which > leave out components? Who makes sure the binaries still work? My > experience with the last mass-rebuild is bad, Nevertheless it had been much better than what is being tried now. > btw, since some packagers > performed major version upgrades shortly after the rebuilds had been done. Packagers perform major upgrades when they "happen". In some cases it's a random point in time, in some cases it's the mass rebuild co-incing with "last minute" updates. It has happened and it will happen again, you can't prevent it, and I don't see any reason why one would want to prevent it. > > > We may remove what's broken and track it on the FC5Status page in the > > > Wiki just as we did for FE4 and older. > > > > Well, let's see how this whole thing works out. But what I'd really like > > to remove before we publish FE5 are old packages from the tree when a > > successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in > > the FE5 tree remove foo-1.2.FC4. That okay for everybody? > > A normal yum update/upgrade only sees the latest one anyway. Partial mirroring sees the older version - This renders using local mirrors of devel over a low bandwidth connection tedious. Ralf -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
