On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier <[email protected]> wrote: > On Wed, 18 Jan 2012 15:23 +0100 > Agostino Sarubbo <[email protected]> wrote: >> 3) Check your rdepend, where is possible with scanelf[3] and if you >> declare it, please, as you said, exclude gcc/glibc and all package >> from @system > > imho this has nothing to do with stabilization, every single package > should have these 2 points addressed.
True, although unless I'm missing something I don't see the harm in listing packages as (R)DEPENDS that are in @system. If anything this would help to reduce churn down the road as we try to minimize the system set. If including packages from @system does break things like stage3s I'll rescind my remarks, but my impression is that all the circular deps necessitated some level of hard-coding in the scripts already... >> So, you can write one time 'how to' and copy/paste for the future >> stablereq; I guess I'm not asking a long and difficult task. > > what i dislike in this approach is that arch testers will follow a > test plan which the maintainer has obviously tested before and knows > it works. > sending people into the jungle of 'try to do something with $pkg' may > make them encounter problems the maintainer hadnt thought about. Yes and no. First, maintainers often run ~arch packages with ~arch dependencies. They are also likely to test on one of x86/amd64, but not both, or perhaps only in a 32-bit chroot where stuff like init scripts isn't really running/etc. Arch teams should be testing on stable systems running consistently on the same arch (no chroots, minimal package.keywords, etc). Arch teams due to dumb luck are also likely to be running different USE flags. So, I don't consider repeating tests as a real waste (trust me, at work I'm all over this sort of thing as we waste a lot of time running tests we know will pass due to NIH syndrome). Also, a maintainer might be able to suggest things that are more likely to break, or which are more likely to cause their users pain. If some aspect of a package is more fragile, then pointing that out to a tester is a good thing. No harm in having the arch team bumbling about a little, but unless a package is perceived as being fairly important I suspect most won't do a great deal of this. All that said, this is Gentoo - if you want a distro with 3 releases per year with coordinated beta cycles where everything is tested together, look elsewhere. Without doing this sort of thing we're going to have to accept that bugs are more likely to crop up (but will likely be fixed faster when they do) - release somewhat early, release very often is a pretty good summary about what we're about. Rich
