On Wed, Jan 18, 2012 at 9:55 AM, Alexis Ballier <aballier@g.o> wrote:
> On Wed, 18 Jan 2012 15:23 +0100
> Agostino Sarubbo <ago@g.o> 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