| 1 |
On Sun, Feb 16, 2014 at 8:48 AM, Jeroen Roovers <jer@g.o> wrote: |
| 2 |
> The (slightly rhetorical) question was how an understaffed team could |
| 3 |
> be realistically expected to start maintaining ebuilds. Your entire |
| 4 |
> reply missed that point. |
| 5 |
> |
| 6 |
> The answer to the question is that you can't. A package maintainer |
| 7 |
> cannot burden an understaffed team with more work. They are |
| 8 |
> understaffed, so they will not do the work, and the maintainer has an |
| 9 |
> itch to scratch (stop maintaining an older version of a package). |
| 10 |
> Now guess who will be actually doing the work. |
| 11 |
|
| 12 |
Well, they can assign the burden to an understaffed team if the team |
| 13 |
wants them to. |
| 14 |
|
| 15 |
Perhaps an intermediate solution is that when a STABLEREQ gets stale |
| 16 |
the maintainer posts in it their intention to drop the old version in |
| 17 |
30 days. The maintainer has to wait at least that long, and if during |
| 18 |
that time a minor arch team asks them to keep the old version around |
| 19 |
then all relevant bugs get reassigned to them, otherwise the |
| 20 |
maintainer is free to delete it. |
| 21 |
|
| 22 |
That leaves the choice with the minor arch team, with deletion being |
| 23 |
the default. |
| 24 |
|
| 25 |
Honestly, I'd probably be fine with the maintainer breaking the arch |
| 26 |
stable tree when removing the package. The arch stable tree isn't |
| 27 |
really stable in the first place if nobody is caring for it, and there |
| 28 |
really aren't any pretty solutions to that problem. |
| 29 |
|
| 30 |
Rich |
Archives