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