On Wed, Aug 03, 2011 at 04:26:20PM +0000, Alexey Dokuchaev wrote: > But if mastersite is still up'n'running, how can we declare that they > are abandoned by upstream?
Because the upstream says that they no longer support the software? > > No upstream == most of the time no maintainenance, no more patches, no > > more security concern. For us it also mean more things to take care of, > > Maybe that means that the software is stable and "just works". Why patch > it then? :-) We've seen plenty of evidence of how badly ports bitrot when new compilers come in, not to mention changes in libc and other places in src. > But mere lack of maintainer or recent upstream activity is not enough: > lots of programs happen to just work so no new version is actually that > needed In that case, some FreeBSD committer should agree to become the upstream, once the upstream is no longer interested; or find someone else out on the Internet to do so. IMHO. > unmaintained ports often get much better care from Kato compared to plethora > of low quality "maintainer update" PRs that get committed these days. Please, when you find a low-quality commit (in terms of functionality -- I know that you and I will not agree on cosmetics), then please bring them to the attention of portmgr. And, not all the Kato-submitted PRs are of equal quality. > Unfortunately, very few maintainers are top-notch folks, I think this is an unnecessary slam on our maintainers. I will agree that some maintainers are much more rigorous than others, of course. > and The Project currently has no educational programs to improve this > situation Most of the education goes on behind the scenes, in private email, on IRC, and so forth. My view, which I know I have repeated before, is that posting generalities to the mailing lists does not solve specific problems. I believe that identifying the specific problems and working the the maintainers and committers one-on-one is a much more effective approach, and that's the approach I take. e.g., I try to follow the management dictum "praise in public, criticize in private", especially with new contributors. YMMV. mcl _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[email protected]"
