| 1 |
On Sun, 16 Feb 2014 09:38:20 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> Basically that one version of the package is now maintained by the |
| 5 |
> arch team. Yes, I know they won't maintain it. The only people that |
| 6 |
> impacts are those who use the arch, who are free to join the arch |
| 7 |
> team and help out. My sense is that they'd prefer having it around |
| 8 |
> to having it deleted. |
| 9 |
|
| 10 |
That's a bit simplistic. What if said package or its newer version is |
| 11 |
required for dozens of other packages, or if the old ebuild needs an |
| 12 |
outdated eclass, or if the old version has a security issue? You can't |
| 13 |
just "assign" all of the old KDE ebuilds to an arch team, for instance, |
| 14 |
or keep texlive 2010 in place because you have "delegated" |
| 15 |
responsibility for it. |
| 16 |
|
| 17 |
Also, every time *I* look at eshowkw's output for a package I maintain |
| 18 |
(which I assume every ebuild developer does or they should hand in |
| 19 |
their badge) and see a lingering old version, it really itches. The |
| 20 |
mere knowledge that I have "delegated" its maintenance to someone else |
| 21 |
wouldn't make me feel better at all. Amplify that with reverse |
| 22 |
dependencies. |
| 23 |
|
| 24 |
> The reason why this thread seems to go on forever is that it seems |
| 25 |
> like the users of the minor archs don't like the status quo. |
| 26 |
|
| 27 |
Examples? :) |
| 28 |
|
| 29 |
> >> That leaves the choice with the minor arch team, with deletion |
| 30 |
> >> being the default. |
| 31 |
> > |
| 32 |
> > Yes, but "understaffed" so nobody is making any choices here. |
| 33 |
> |
| 34 |
> Well, if they make no choice then the maintainer deletes the package. |
| 35 |
> That's what you want, right? The package would only stay around if |
| 36 |
> the minor arch asked them to. If they don't do that, then nobody can |
| 37 |
> complain. |
| 38 |
> |
| 39 |
> However, I don't think it makes sense to enact changes like these |
| 40 |
> unless the minor arch teams actually speak up about wanting the |
| 41 |
> changes. If they don't I'd be inclined to just clarify that |
| 42 |
> maintainers are welcome to trim old stable versions on minor archs if |
| 43 |
> the bugs are older than n days. |
| 44 |
|
| 45 |
That still leaves maintenance problems on dependent packages and |
| 46 |
eclasses and security issues and what not. |
Archives