On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote:
[...]
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.)
Are these three tiers documented anywhere? It's difficult to follow
rules you don't know. It's also difficult to make suggestions about an
opaque system.
11MB sounds huge. I have no idea what to make of that number. Is there
a reason why we can't shrink the specification of the tiers to
something more manageable?
Best of all would be if we could, at least for the collections, embed
the tier separation rules within the code itself (eg, info.ss files or
similar). Then we could make the standard module name resolver enforce
the rules automatically, giving developers immediate notice of breakage.
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.
How about having an email automatically go out to plt-dev if the
nightly build fails? Perhaps with a record of the svn commits that
might have triggered the failure, if that's feasible.
Ryan
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
