| 1 |
On Sun, 16 Feb 2014 09:22:49 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> Well, they can assign the burden to an understaffed team if the team |
| 5 |
> wants them to. |
| 6 |
|
| 7 |
Achieving nothing in the process, even if the understaffed team |
| 8 |
actually responds. |
| 9 |
|
| 10 |
> Perhaps an intermediate solution is that when a STABLEREQ gets stale |
| 11 |
> the maintainer posts in it their intention to drop the old version in |
| 12 |
> 30 days. The maintainer has to wait at least that long, and if during |
| 13 |
> that time a minor arch team asks them to keep the old version around |
| 14 |
> then all relevant bugs get reassigned to them, otherwise the |
| 15 |
> maintainer is free to delete it. |
| 16 |
|
| 17 |
It isn't policy, maybe, but that's just common sense: |
| 18 |
|
| 19 |
1) Request stabilisation. |
| 20 |
2) Ping and wait. |
| 21 |
3) Ping and wait. |
| 22 |
4) Ping and wait. |
| 23 |
5) Solve the problem yourself. |
| 24 |
|
| 25 |
It's been done like this since forever. |
| 26 |
|
| 27 |
> That leaves the choice with the minor arch team, with deletion being |
| 28 |
> the default. |
| 29 |
|
| 30 |
Yes, but "understaffed" so nobody is making any choices here. |
| 31 |
|
| 32 |
> Honestly, I'd probably be fine with the maintainer breaking the arch |
| 33 |
> stable tree when removing the package. The arch stable tree isn't |
| 34 |
> really stable in the first place if nobody is caring for it, and there |
| 35 |
> really aren't any pretty solutions to that problem. |
| 36 |
|
| 37 |
Indeed. |
| 38 |
|
| 39 |
|
| 40 |
|
| 41 |
jer |
Archives