Hi Michał, Michał Górny <mgo...@gentoo.org> writes:
>> I am on the toolchain alias, and I am interested in joining the project. >> I will be responsible to deal with all the bugs for glibc-2.16 and >> glibc-2.19. Bug wranglers' work load does not change. >> >> Yes, I apologize this will generate some noise for toolchain@g.o. But I >> anticipate people on the team are interested in receiving those emails. > > That's not a solution. That's cheap a cheap excuse that works for one > package, for today. It does not solve the generic case, What I ask is a special treatment of glibc. I do not intend to explore a generic solution in this thread. And don't get me wrong, I support tree cleaning by all means. Glibc is special, llvm is the only other (not so similar) example. No more package will be special like this. This will not set a bad example or bad excuses for keeping outdated ebuilds. I don't see your argument of generic case. > it does not mean that other members of toolchain or any other team > will not end up having to remember extra rules like 'do not remove > this ebuild because X wants it'. Is that a problem? When at least 1 person is eager to maintain an package, the package could be kept. Consider that person as the de facto upstream. Consider glibc-2.16 as a sys-libs/glibc-revived package that is too closely connected to sys-libs/glibc be treated as a 2nd package. Then the package argument carries to a special version of ebuild. Cheers, Benda