On May 20, 2009, at 7:22 PM, Ryan Schmidt wrote:
This is the second time you've closed this ticket for the sole reason that the problem occurs only on Panther. I previously reopened this ticket explaining that's not a good reason for closing. You've closed other tickets for the same reason. Up to now, we have not had a policy of closing tickets for the sole reason that they are Panther-specific. While we do not officially support Panther, the policy thus far has been that we would still accept patches to fix things for Panther. I find it useful to have bug reports filed for issues, even if a fix is not immediately known, that way interested parties can see the report and Cc themselves and offer input. The number of open tickets in the database has no bearing on this. If you would like MacPorts to adopt a policy of declining to fix Panther issues and immediately closing Panther tickets, let's discuss that proposal here.
OK, so, let's discuss it. I'll start: I think continuing to support Panther, even by inference or continued acceptance of patches to support it, is a really bad idea and here are some (though by no means all) of the reasons why it's a bad idea:
1. Every #ifdef or Panther-only work around adds to the overall support burden of MacPorts. Some day, assuming MacPorts lives long enough to have such problems, most of the current set of people will be retired / MIA / dead and it will fall to a new crop of engineers to support the aging ball of goop collectively known as MacPorts. For each and every line of legacy support code, the justification(s) for which will have long since vanished into the fog of history, the burdens on these people will only be increased. Think of your successors ("think of the children!") even if it's a burden you, personally are willing to shoulder today.
2. The marketing figures are not generally available, nor can I make such figures generally available, so you're just going to have to take my word for it that the overall percentage of Apple customers still running Panther is small. It might be a user base which is occasionally loud, in certain specific cases, but that still does not make it large or even noteworthy. "The needs of the many outweigh the needs of the few", to quote Spock (and what argument isn't instantly won by quoting Spock, I ask you? :-). If you're not someone who goes in for Spock, then simply substitute the law of diminishing returns.
3. At the risk of stating the obvious, you are an open source project that provides its labor for free. Given that fact, there will also always be users / companies / evil foreign governments who are more than willing to ask for, nay demand, the moon and the stars because there are these silly people giving celestial objects away for free, or so they heard anyway, and WHAT HAVE YOU DONE FOR US LATELY? In such an environment, it has also been shown that the decibel level of ambient whining can be significantly decreased once the project demonstrates some ability to set and enforce the boundaries of "just what we're willing to do", drawing various lines in the sand when appropriate. An n-release support policy, where n is some mutually agreeable constant (my favorite is "2"), is also one such useful line in the sand to draw.
- Jordan _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
