| 1 |
On 1/26/11 3:14 AM, Ryan Hill wrote: |
| 2 |
> On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal |
| 3 |
> <scarabeus@g.o> wrote: |
| 4 |
> |
| 5 |
> Won't this just pile on more work on already stressed to the max arch |
| 6 |
> teams? As in, now they have to stabilize more packages to get back to |
| 7 |
> where they were in the first place? |
| 8 |
|
| 9 |
This seems to be a self-balancing system to me. If the arch team is so |
| 10 |
stressed that it can't stabilize something within 90 days, and can't |
| 11 |
even state a reason for that, just move the package back to testing. |
| 12 |
|
| 13 |
After some time, the stable set for that arch should be small enough to |
| 14 |
let the arch team handle it on time. |
| 15 |
|
| 16 |
> And as I understand it, the reason maintainers are complaining is |
| 17 |
> because they want to drop old versions. |
| 18 |
|
| 19 |
I'm not sure why maintainers are complaining, but generally managing |
| 20 |
bugs that sit there for a long time is harder. |
| 21 |
|
| 22 |
> Meaning stable users of these archs can suddenly lose large parts of |
| 23 |
> the tree if this happens. From their point of view, we've just |
| 24 |
> broken perfectly working systems. That's pretty much the opposite of |
| 25 |
> what stable is supposed to promise. |
| 26 |
|
| 27 |
That's an important point. I think that a message should be sent |
| 28 |
somewhere (gentoo-dev-announce?) that something like that is going to |
| 29 |
happen, and wait some 60 days for someone to save the package. |
| 30 |
|
| 31 |
> And I've never been an arch tester, but I bet after the first few |
| 32 |
> times I tested a package only to have it dropped to ~arch because no |
| 33 |
> developer was around to commit the keyword change, I wouldn't feel |
| 34 |
> much like doing it anymore. |
| 35 |
|
| 36 |
Good point. |
| 37 |
|
| 38 |
> How about the opposite? If everyone but $arch has stabilized the |
| 39 |
> package, and you can't get a response from them in a reasonable time, |
| 40 |
> then use your discretion as maintainer and mark it stable yourself. |
| 41 |
|
| 42 |
Very dangerous, especially for exotic arches. I think we should not go |
| 43 |
that way, or at least _require_ the maintainer to test on that arch. We |
| 44 |
have some development machines for various arches so it should be |
| 45 |
technically possible. But it generally seems to me that maintainers miss |
| 46 |
more problems than arch testers/developers. |
| 47 |
|
| 48 |
> Arch testers would remain useful by giving the maintainer some |
| 49 |
> measure of assurance that they won't accidently break anything for |
| 50 |
> that arch. |
| 51 |
|
| 52 |
Good point, again provided the maintainer at least compile-tests the |
| 53 |
package on that arch. |
| 54 |
|
| 55 |
Paweł |
Archives