On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers <[email protected]> wrote: > On Sat, 15 Feb 2014 11:41:57 +0100 > Tom Wijsman <[email protected]> wrote: > >> While it was not explained here, the idea can also move the actual >> maintenance of the ebuild to the arch team; such that it becomes the >> arch team's responsibility to deal with it, or rather don't deal with >> it > > How would that ever work? You have some old cat/pkg/pkg-version.ebuild > that you no longer want to maintain, but which happens to be the latest > stable for $ARCH, which is apparently understaffed because they $ARCH > hasn't tended to a related bug report in months, and now you want to > leave the ebuild in place and also expect $ARCH to start maintaining > it? How does $ARCH have the man power to do that, again?
Many objected to removal since old with minor issues is better than new that doesn't work at all on some archs, or so the argument goes. This thread has gone on for a while, but at least this is a new suggestion. If we were torn between these two options (removal or re-assignment), then we could potentially leave the decision up to the arch team. If they speak up they can get bugs assigned to them, and if they don't speak up they get their stable packages removed. And I'm all for other options, but beyond more manpower I'm just not seeing anything that is going to be pretty. > Nobody is reading those bugzilla e-mails - nobody is working on > keywording/stabilisation for $ARCH. "Nagging" is pointless when > nobody hears you, and an e-mail from bugzilla isn't > magically better prioritised when Assignee: changes. I think the point is that the maintainer doesn't see the nags. If nobody else sees them either it is "somebody else's problem" from their standpoint. That isn't going to make the bug submitter very happy, but if removal of the only version of a package that works on their arch entirely is the alternative I suspect they will live with it, or better still join the arch team. Removing the package version entirely is the tidy solution from a tracking/bugs/etc standpoint. The problem is that for the end user it might mean taking away something that at least somewhat works and leaving them with nothing. Fixing the new version probably isn't an option if somebody isn't willing to step up, so the question is just whether we keep around the old version. The new suggestion is to keep it around, but not to bug the maintainer with the resulting issues. If an old version gets to the point where it is simply unusable it should almost certainly be dropped. That at least avoids constantly pestering the bug wranglers/etc with dups, and gives the arch team a bug list where at least they have some hope of doing something. Rich
