On 01/12/2010 01:30 PM, Markos Chandras wrote:
IMHO ( this is not a treecleaners@ opinion, i m just talking for my
self ), announcing and masking a package is a good way to inform and wake up
everybody to take care of this package if they really really want to stay on
portage.

I agree with the announce part, and the THREAT of masking. I just don't think that the masking should happen at the same time as the announcement.

Having open bugs for months isn't a way to let everybody know that this
package is broken for long time, so it is a valid candidate for removal?
Should we send that via e-mail as well?

I don't think an open bug constitutes notice. It is valid notice to the maintainer of the package, but not to the larger community.

I probably have 100-200 packages installed, and I'd probably be annoyed if any of them went away (I'm still missing kdirstat, but that isn't really the kde team's fault). If an important one was about to go away I might step in to maintain it, and I'm sure a lot of other people feel the same way. At the same time, I can't monitor the bugs on 100-200 packages - that is the reason for having a maintainer.

I think the concern is that some maintainers don't respond in a timely manner. Now, I don't know that maintainers have an obligation to fix every bug within a certain timeframe - some packages are problematic and I'm not sure that we should discard a 98% solution in favor of a 0% one because we don't have a 100% one. However, serious issues should be in scope for treecleaners, but the first goal should be to find a maintainer, and only if that fails should we consider masking.

Also - if a maintainer can't be found we might also try to coordinate with the Sunrise folks to see if they're willing to take it over.

We should also solicit proxy-maintainers among the user community when we announce pending removals. That could be very helpful with something like inn: I use it VERY lightly and I'm not a news guru, but I am a dev. I bet we have users who are news gurus and who care about inn, but they aren't Gentoo devs. Together we could probably cover the gaps and I'm sure devs would be more willing to pick up a package if they knew they had some help with the nuances of the package itself. If that falls apart later, at least an active dev is assigned to the package, and they can always decide to try to find a new maintainer or kill the package (saving treecleaners the work of doing so).

In short - treecleaners should be about getting packages back into the mainstream maintenance model, with removal being the fallback option if that doesn't work. They shouldn't have to go out of their way to do this, but an advance announcement and some coordination is probably a good idea.

Rich

Reply via email to