| 1 |
On 9/29/13 11:14 PM, Agostino Sarubbo wrote: |
| 2 |
> If you look at the policy, it says to test few rdeps. |
| 3 |
|
| 4 |
And I think this is right. If you'd like things to be done in a |
| 5 |
different way, discussing them is OK, but "unilaterally" just skipping |
| 6 |
that is not OK. |
| 7 |
|
| 8 |
> The arch tester is in charge to test the packages on his architecture. |
| 9 |
> These type of failures are _not_ architecture dependant. |
| 10 |
|
| 11 |
It depends. It certainly can be package-version-dependent, and this can |
| 12 |
vary by arch, even between x86 and amd64. |
| 13 |
|
| 14 |
> So, instead of have 10 ATs that are testing the same rdeps, seems logic |
| 15 |
> that the maintainer could do it one time. |
| 16 |
> |
| 17 |
> What do you think? |
| 18 |
|
| 19 |
It's not always the maintainer who files the stabilization bug. It can |
| 20 |
be a user, or it can be me using automated scripts (which for the first |
| 21 |
bug submission ask for maintainer's OK). |
| 22 |
|
| 23 |
One possible option is for arch teams to refuse to do stabilization bugs |
| 24 |
not explicitly approved by maintainers. If everybody agrees that such |
| 25 |
approval also means testing reverse dependencies, it may be a move in |
| 26 |
direction you're saying. |
| 27 |
|
| 28 |
Now you've used an argument of scale: 10 ATs doing the "same thing" |
| 29 |
(which btw I rarely see so many AT reports in one bug) vs. just 1 |
| 30 |
maintainer doing that. |
| 31 |
|
| 32 |
I think that's a too local view. When you take the whole stabilization |
| 33 |
queue into account (at least 80-120 bugs, below that it's not worth it |
| 34 |
to me) you can save a lot of time through batching. Here's how: |
| 35 |
|
| 36 |
1. On a fully stable system (even before testing packages to be |
| 37 |
stabilized) emerge the reverse dependencies to make sure they currently |
| 38 |
work (sometimes they're already broken in the stable tree, and some |
| 39 |
packages to be stabilized actually fix these breakages). This can easily |
| 40 |
take an overnight emerge, so it's good to put as many packages there as |
| 41 |
possible to use that time effectively (and emerge's --keep-going option |
| 42 |
is very helpful). |
| 43 |
|
| 44 |
2. Emerge the packages to be tested. Usually another overnight emerge. |
| 45 |
|
| 46 |
3. revdep-rebuild and all usual actions after updating the system. |
| 47 |
|
| 48 |
4. Explicitly re-emerge the reverse dependencies again and compare the |
| 49 |
results with run from (1). This would usually also take a long time on |
| 50 |
my machine, so it's good to batch as many packages as possible. File |
| 51 |
bugs for any regressions and do not stabilize packages introducing the |
| 52 |
breakages. |
| 53 |
|
| 54 |
As you see, the arch team member can do the all ~100 packages in about |
| 55 |
3-4 days, and most of the process doesn't require human input. Most of |
| 56 |
the time is spent reviewing the bugs (I have a script for that called |
| 57 |
bugzilla-viewer.py which also displays related bugs and repoman output) |
| 58 |
and reviewing the error messages for packages to be tested and reverse |
| 59 |
dependencies. This is more effective the more packages you have, so arch |
| 60 |
team member has a great advantage here being able to batch ~100 packages |
| 61 |
instead of asking several maintainers to do their tests. |
| 62 |
|
| 63 |
Of course it's good when maintainers also do their own testing in |
| 64 |
stable, but I wouldn't block stabilization on that. IMHO instead of |
| 65 |
trying to put the blame/duty on either maintainers or arch teams, the |
| 66 |
right question to ask is what's the best process to do stabilizations well. |
| 67 |
|
| 68 |
Paweł |
Archives