Am 07.09.2011 17:53, schrieb Mikhail T.: > The policy -- up until fairly recently -- was to remove ports, that > *fail to build* for a while. This made sense -- if the port remains > unbuildable long enough, then, certainly, it is no longer in use. > > The /new/ policy of removing ports for much lighter offenses, such as > having vulnerabilities, has already caused so many objections, that it > is time to abolish it.
I don't see ports being killed the first day they are vulnerable. They are killed if they're dead and vulnerable though, and that's good. > A "maintainer timeout" will allow another developer to perform a fix. To > completely remove the port (if that has to happen at all), a much longer > warning is warranted. Which can certainly be negotiated (and an EXPIRATION_DATE shifted) if and only if the fix is really going to happen. A case like "I'll fix it after vacation" might be workable. However if you make empty promises repeatedly noone will care. > Yes, the matter is exactly that: your wanting to remove something, that > continues to build and remains in use. You followed, what you think is > "an old" policy, and are getting flack from people like myself, who > object to the (new) policy. Nothing personal... End users are not obliged to delete ports we've removed from the ports, so I wonder what the heck the difficulty is with "we no longer care". We're not enforcing port removals on end user's computers. We're not Google removing applications from your Android phone. We're not Apple doing the same to your iOS phone. So can this discussion be ended? If the port was in active use and maintained, we would not be deprecating it. > Again. This is not about a particular port -- Julian, myself, and other > objectors can fix /any/ port, but we can not fix them /all/, so blaming > us for not submitting patches is wrong. Rather than waste your time discussing that you could go maintain and/or fix the ports you feel should not be deprecated. > We object to the new policy, because we believe, only those ports, that > fail to build, ought to be removed. Problematic ports ought to remain in > the tree (as long as they build) -- to make it easier for people to > continue using them and/or offer to maintain them. If there remains a > vulnerability, then, of course, a loud warning (with a link to the > advisory(ies)) is in order, but the users ought to make their own > choices and evaluations. They do even after port removal. If a port is known broken and there is no prospect of a fix, it must go. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
