OK, I'm sure what I'm about to say will identify me as a total kill-
joy who also somehow doesn't remember the bad old days of base/
instability or synchronization issues between base/ and dports/, but
please just take it as a given that I DO remember those problems and
still feel compelled, given some of the more negative trade-offs I've
been seeing, to make the following statement anyway:
I don't think MacPorts should be doing releases.
Why? Because I think they're premature for the project in general
(given where it is in terms of resources and technology), I think
they're largely arbitrary in what they're able (or willing) to
promise to users and I think that they tend to create more problems
than they solve as users attempt to follow the releases for base/ but
still want to effectively follow ToT for dports/, leading to
something which looks more like FrankenPorts than a genuinely
coherent and stable branch.
What's worse is the fact that these "releases" are highly misleading
in the sense that a "release" for any other software product is
something that enjoys not just a "freeze" period but some sort of
quality control and testing which ensures that all the respective
pieces actually hang together and there aren't any really egregious
problems with the product on the date that it ships. MacPorts, on
the other hand, does not have any sort of testing infrastructure to
guarantee (or hell, even KNOW) that a significant majority of the
ports are working at that particular time or that base/ and dports/
synchronization problems have not broken things in various dusty
corners of the ports collection. This is why I say that the
MacPorts project itself is simply not release-ready; it's more like a
project going through its early Alpha stages where "be careful, you
might cut yourself!" is about the best advice any user can be given.
Of course, we could attempt to dodge the issue here and claim that
releases were really only for base/ and dports was the uncharted
territory, but that would be silly given that if you add up every
single line (of anything) in base/, you're looking at 156,000 lines
of Makefiles, C, Tcl and other miscellaneous goop whereas for dports,
that number is over 713,000 lines. If anything needs release
control, it's dports/, and one possibly helpful analogy would be to
suppose that Mac OS X was released every time xnu looked stable
enough, never mind everything else that depended on xnu. "Not
really our problem", the Mac OS X engineers might say. "People will
certainly tell us if Mail, Final Cut Pro or various 3rd party are
completely hosed and we can always fix that in the next release."
That would sure be a lot easier (and I could spend the bulk of the
year on Maui instead of worrying about the bulk of the bugs I worry
about) but it wouldn't be a release.
1.4, despite all the hard work people have put into it, is also not a
release. Neither was 1.3, or 1.2, or anything that DarwinPorts/
MacPorts has done. They've been fingers stuck in the wind and a
highly subjective attempt to decide "what would be a good time"
without the benefit of any actual end-to-end testing or regression
analysis. If that's all they were, I also probably wouldn't say
anything, figuring "ah, what the heck, let the kids have their fun!",
but I'm noticing more and more that these pseudo-releases are also a
drain on productivity and end up spending cycles doing merges and
trying to figure out how to change the behavior of things in base/ in
ways that might effects many different ports, even when those
improvements are worthwhile.
My proposal is that work continue on ToT and this premature notion of
releases be dropped until MacPorts is truly ready to run through all
of its ports and figure out what's broken and what's not.
Speculative development can still be done on branches and need not
perturb ToT until all the pieces are ready to come together, but ToT
should simply be the commonly-advancing front of MacPorts and if
something is broken, a user who tracks it can generally be assured of
a fix (either in base/ or dports/ as applicable) simply by keeping
their tree up to date and waiting 24 hours.
As I've also implied in the previous paragraph, I don't think
releases are a bad idea *eventually*, I just don't think it's
something MacPorts should be doing until it substantially improves
its technology to the point where the general health of MacPorts, and
I do mean all the ports and possibly even "their popular variants"
are testable.
- Jordan
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
