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