[plt-dev] component delivery, a social experiment

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Tue Nov 10 12:20:14 EST 2009

Ladies and gentlemen,

Eli spent my first hour++ in my office this morning pointing our  
serious flaws in our world. Here are two important points, and I am  
putting them up for discussion here with a request for sensible  
comments:

1. In some way we have been conducting a social experiment for the  
past 10 days or so. As you all know, Eli spent a considerable time  
creating the nightly build framework when he first arrived here. From  
the nightly build, Eli's software also creates a nightly set of  
deliveries and puts them up on the web somewhere. What you ma not  
realize is that the nightly builds have been broken for some 10 days  
due to the check-in of a module that breaks the component delivery  
mechanism.

Nobody complained, so our conclusion was that nobody noticed. Our  
second corollary was that perhaps we only have a camel-back  
distribution of users: those who use svn and build from svn and those  
that use only the releases. (As Eli walked out of my office, I  
switched to my email and the first message contained a complaint about  
the missing nightly deliveries. This means we know of one user of the  
deliveries.)

2. Which brings me to the topic of "delivery by component." Apparently  
few, if anyone here, is aware of Eli's carefully arrange delivery  
layers:

  -- smallest: plain mzscheme, no mred, no docs
  -- mid size: mred, drscheme, no docs
  -- largest:  everything

Eli tells me that there are numerous people who use 'smallest'; I  
don't know about mid.

He (and I and I know Robby) have for a long time envisioned a delivery  
system that starts with a core package and then asks (possibly via  
some gui) what other packages should be installed, e.g., the 'mred'  
layer or the server. The three-tier delivery system is a first step  
toward this component-oriented delivery.

Eli has carefully maintained a dependency graph and list (that takes  
some 11megs) among the various files (8 platforms, 3 tiers, everything  
spelled out). Since people aren't really aware of this system, they  
easily and apparently relatively often break the non-cyclic  
dependencies. (I am guilty of doing this myself when I wrote the first  
docs that depended on slideshow.)

In my opinion, we have two options:

  -- drop the dependency system and just deliver one large package
  -- enforce the dependencies. If you break them, you get a message.
     If you don't clean them up in N hours, the file is removed.

;; ---

As I said, sensible comments welcome. -- Matthias






Posted on the dev mailing list.