Re: [plt-dev] component delivery, a social experiment
I personally don't see any value in leaving out the docs or DrScheme. Everything is so small anyways and hard drive space is cheap... I don't get the use case. Jay On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Thanks for the responses. The responses propose three natural things: 1. We need the nightly builds. 2. Eli's component rules must be turned into something that people can read up on. 3. The email about rule violations should not go to Eli but to plt-dev. (It's all implemented, no need to shift it anywhere.) ;; --- There were no comments on component-oriented distribution. -- Matthias On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: 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 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
On Wed, Nov 11, 2009 at 11:57 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I personally don't see any value in leaving out the docs or DrScheme. Everything is so small anyways and hard drive space is cheap... I don't get the use case. I believe that there are people who want to install the text interface on systems where GUI libraries are not available. But beyond that, I don't see a point. However, before we make this hard, we might want to talk to the people who package PLT for Fedora/Debian/etc. sam th Jay On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Thanks for the responses. The responses propose three natural things: 1. We need the nightly builds. 2. Eli's component rules must be turned into something that people can read up on. 3. The email about rule violations should not go to Eli but to plt-dev. (It's all implemented, no need to shift it anywhere.) ;; --- There were no comments on component-oriented distribution. -- Matthias On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: 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 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
On Wed, Nov 11, 2009 at 12:46 PM, Sam TH sa...@ccs.neu.edu wrote: On Wed, Nov 11, 2009 at 11:57 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I personally don't see any value in leaving out the docs or DrScheme. Everything is so small anyways and hard drive space is cheap... I don't get the use case. I believe that there are people who want to install the text interface on systems where GUI libraries are not available. But beyond that, I don't see a point. However, before we make this hard, we might want to talk to the people who package PLT for Fedora/Debian/etc. Some people don't use PLT because it is perceived as bloated. They would like a download that has only mzscheme and no documentation or IDE. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
I like the availability of a mzscheme-only package - it allows you to deploy a minimal system in a production environment. Thanks, yc On Wed, Nov 11, 2009 at 8:57 AM, Jay McCarthy jay.mccar...@gmail.comwrote: I personally don't see any value in leaving out the docs or DrScheme. Everything is so small anyways and hard drive space is cheap... I don't get the use case. Jay On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Thanks for the responses. The responses propose three natural things: 1. We need the nightly builds. 2. Eli's component rules must be turned into something that people can read up on. 3. The email about rule violations should not go to Eli but to plt-dev. (It's all implemented, no need to shift it anywhere.) ;; --- There were no comments on component-oriented distribution. -- Matthias On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: 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 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
YC wrote at 11/11/2009 01:55 PM: I like the availability of a mzscheme-only package - it allows you to deploy a minimal system in a production environment. This could be the more important use case for providing a stripped-down packaging of PLT: people who want to run the PLT Web server for real server deployments. Size matters, especially if you're paying for disk space to a managed-server hoster or cloud hoster. But even if you're hosting your own servers with big disks, having to install all the GUI and docs on each server reduces credibility (unless PLT makes a case somewhere for having a full development environment on every deployed server). -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
I, for one, am quite happy that we have a nightly build and hope that we continue to have it. I suspect that anyone that uses Windows and wants to keep up from SVN also benefits, since building under Windows is not an easy thing to do (unlike the other platforms we support). I don't think the option two below you mention is feasible, simply because removing the file is likely to break the build in some other way. But perhaps we can have some other Bad Thing that happens (public blame anyone?) when someone breaks the build that would help get us back in shape quickly. Robby PS: for the record, I complained twice to Eli about the currently broken build, once when I noticed it because I wanted to point someone to recent docs and then later when someone else contacted me about it. So no one noticed is just plain wrong. On Tue, Nov 10, 2009 at 11:20 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] component delivery, a social experiment
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
Re: [plt-dev] component delivery, a social experiment
I, for one, am quite happy that we have a nightly build and hope that we continue to have it. I suspect that anyone that uses Windows and wants to keep up from SVN also benefits, since building under Windows is not an easy thing to do (unlike the other platforms we support). I know other people who use the nightly build regularly on Windows. And the nightly build docs are quite valuable. I've also benefited from the nightly build catching bugs that I've introduced. FWIW: I always use the nightly builds, both in Windows and MacOS. (I coroutine between theorems and programs for my research, and I've been in theorem-proving mode, so I haven't updated DrScheme in a couple months-- which is why I didn't notice this time when it went down.) Dave _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
