Why are we doing releases again?

[Jordan K. Hubbard]

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