Forum OpenACS Q&A: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST

Collapse
24: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST (response to 1)
Posted by Don Baccus on 10/04/02 07:11 PM 
I think this discussion would be more productive if
we focused on the technical issues at hand, behaving objectively and
stopped with personal comments/attacks. There's simply no need for
that and it doesn't do any good to anyone.
Well, doh! That's why I find Ben's propping up of strawmen to knock down, strawmen based on a misrepresentation of truth, strawmen that misrepresent my personal position, so offensive. What is technical about this approach?

Sorry, when my position is misrepresented to this extent, I'm not going to sit by quietly. Ben and I had this discussion months ago, after which Ben stated that he understood my position regarding monolithic releases and synchronous schedules, and that he would agree that new-portal should be part of the OpenACS, rather than the dotLRN, project.

Why is the new-portal issue being raised once again? I'm tired of it. Done deal, folks, right or wrong the discussion's been had and the discussion is over. OpenForce originally proposed a new portal package to be part of our standard OpenACS toolkit. Ben has made no compelling argument that convinces me, at least, that his original decision that it be part of the OpenACS toolkit is wrong. We're sticking with OpenForce's original proposal.

As far as something like MIST, sure, it's a great idea.

I personally think we shouldn't make users depend on it, though. The linux world has apt-get and up2date, the BSD world the ports system.

But they also have ISO images, individual packages available for ftp download. "centralized"? Well, many packages have both their own home *and* a slot on, say, RedHat's centralized ftp server. Why? How about "doing so makes it easier for users"?

Anyway ... before we worry overmuch about how to distribute a modularized distribution, don't folks think that we should first try to figure out whether or not we have the resources to manage such a distribution and, if so, how we'll divide up the work and so manage such a distribution? It is my hope that folks will step up for 4.7 and that we'll have the resources available to discard the monolithic tarball approach as our sole means of delivering code.

But I see no guarantee that this will happen. Personally I'd like to see Open Force step forward and help with this aspect of the problem (not to mention to step forward and help with the nitty-gritty work needed to get 4.6 out the door, i.e. testing, bug fixing, and the writing of missing upgrade scripts). There's no point of writing MIST if we can't gather the resources to properly manage modular releases.

The actual means by which we shove the bits down the user's pipe is not, IMHO, on the critical path. Once we have a more modular distribution we'll probably want to deliver it in several ways.

If we were pushing 600MB down the user's pipe then splitting that delivery into manageable pieces would be absolutely critical, but let's face it, a 10MB payload isn't large enough to bother many people.

How many users have actually complained about the download taking too long? How many users have complained about the initial install of the core taking too long? (the *core*, not all the packages one can load optionally after the initial OpenACS install).

I've received exactly zero such complaints, myself, and as Project Manager I'd expect to hear about it if many were complaining.

So I look at arguments based on size of the existing tarball and install time of the core as being weak, technically, since I see no evidence that any real users are bothered by either issue.

However, we all know that there are other reasons for wanting to move from a monolithic release scheme. It's going to happen, the only question is when, and that's entirely a matter of available resources.