On May 20, 2009, at 11:06 PM, Scott Haneda wrote:
Hijacking this to a new thread. First time posting to the dev list,
be gentle...
On May 20, 2009, at 8:43 PM, Jordan K. Hubbard wrote:
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.
This sounds ominous. I push ports over fink all the time. I never
really knew why, until one day. I saw there were a few apple.com
email addresses on this list, and I also saw it was part of
MacOSForge, which has a tie in to Apple in some way.
I translated this as meaning there was at least a stronger chance of
ports lasting the test of time than anything else.
Anything is possible, though also bear in mind the fact that we
probably have different time-scales in mind for those "ominous words"
I uttered. When I said "some day", I meant "sometime in the next 20
years" since those are the time scales in which I consider software
(unless said software is a computer language, in which case double
that) living a full and complete life-span.
I don't see that MacPorts is in any imminent danger, no. My
prediction is rather that it will continue to grow and slowly morph as
it tracks various Mac OS X releases from Apple. It's specifically the
fact that it has to "impedance match" for each OS release differently
that makes the length of its legacy tail even more critical than it
would be for most software systems, since that matching extends from
the base infrastructure all the way out into the various ports which
sometimes need to specify different platform blocks for each release
variant they're expected to support. That's a big ship to try to send
in 4 directions at once.
If it were me calling the shots, and it's not, what I'd probably do is
fork the entire macports tree with a -legacy branch, the purpose for
which is defined as "everything from Panther back to Cheetah, if
people really want", and leave -trunk advancing along with a "whatever
the last n releases are" support policy, older releases dropping off
into the -legacy branch to die a slower, semi-supported death. Then,
at least, those poor unfortunates who are constrained to $
{someOldRelease} of MacOSX have the option of self-support by being
given a place to work.
- Jordan
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev