On Fri, 23 May 2008, Luciano Bello wrote: > Is not about accept help. It about considering the package as > unmaintained if there is not a team to maintain it. In same > packages, we can not depend on only two pairs of eyes.
If there aren't enough people who are interested in maintaining packages which are not currently team-maintained packages to make them team maintained, requiring them to be team maintained isn't going to do anything. Are there any packages which aren't team-maintained which have maintainers in the wings who have already contributed to development of the package where the original maintainer hasn't considered team maintainership? > Of course at first is not easy. But we should go to an scenario > where all the local patches was reported to upstream (to apply them > in the next release) or be justified by more than one developer. > > I'm just saying the platitude. We need to improve our process. We > must learn something from the Debian/OpenSSL debacle. We've learned lessons that we already knew: reviewing patches and working to minimize diffs between upstream is good. However, blocking Debian development on upstream or reviewers isn't the way to magically get more people to review Debian-specific patches. We need the people who are doing the review and have continuously committed to doing the review before we block on the review. Don Armstrong -- He was wrong. Nature abhors dimensional abnormalities, and seals them neatly away so that they don't upset people. Nature, in fact, abhors a lot of things, including vacuums, ships called the Marie Celeste, and the chuck keys for electric drills. -- Terry Pratchet _Pyramids_ p166 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
