On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke <span dir="ltr">&lt;<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My biggest comments on planet2...<br>
<br>
* I like the general ideas of permitting more decentralized sharing of packages (such as through some kind of Git URLs).<br>
<br>
* I like the idea of making it easier to modify the source of a package and share changes with upstream (which is needlessly cumbersome with PLaneT 1).<br>
<br>
* I&#39;m very concerned about discarding support for mixing versions of packages.  PLaneT 1 didn&#39;t fully nail this, but I suspect planet2 is punting needlessly, rather than getting data and solving problems (perhaps due to changing mission, as speculated in next two points).<br>
</blockquote><div><br></div><div>My rationale is that what OSes provide is good enough for wide uses and we can more easily build the right versioned package system on top of this than a non-versioned package system on top of one that is versioned.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Other than GitHub support, a lot of what I saw in the planet2 documentation was not intuitive to me, wrt how I was thinking would be a good direction for Racket grassroots package development.  It looks like maybe planet2 is biased towards the way core developers work (e.g., centralized, large, monolithic code base, with single version), and/or towards modularizing Racket distributions, rather than towards grassroots package development.<br>
</blockquote><div><br></div><div>I&#39;m not sure how to respond to this because I don&#39;t think it&#39;s concrete enough for me. I&#39;d say that I see P2 has making it easier to not be centralized and to make smaller packages, because they can provide single modules of various collections (like a new data/ package) without having to introduce a whole new namespace. I see a lot of failure in this department with how P1 was used. For example, the various library collections on P1 (like scheme, unlib, etc) seems to me a product of the pain of P1 deployment encouraging monolithic packages.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Related to previous point, it also looks like there *might* (unclear) be a desire to increasingly centralize or canonicalize some of the kinds of library work that I&#39;ve been thinking are generally best done in a more decentralized and organic manner.  If so, have to be careful with this.<br>
</blockquote><div><br></div><div>I assume you are referring to the suggestion to (a) use known collections like data, (b) not give things cute names, and (c) not name things after developers. This would, for instance, make it so that we have &quot;net/soap&quot; package rather than &quot;roap&quot;, &quot;unroap&quot;, and &quot;super-soap&quot;. I think this is a good thing. We should be encouraging collaboration to produce excellent packages rather than having many 20% solutions. It certainly requires more work, but it seems to have had good results in the Perl, Ruby, and Haskell communities where this seems to be the common library creation practice. Nevertheless, these are just guidelines and the system makes no attempt to enforce them.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* We&#39;d talked about planet2 on-and-off for years, but I didn&#39;t realize planet2 was imminent, so I recently somehow managed to spent a lot of unpleasant time working on PLaneT tools and such that now look moot in light of planet2.  Every now and then, the rug gets pulled out from under a non-core developer (this has happened a few times that I know of), and it can be a waste of energy and morale, so we should keep trying to avoid rug-pulling when practical.<br>

<br>
I have numerous small comments, (like, just from glancing at currently open browser window) you probably don&#39;t want to call anything &quot;PNS&quot;, and the names &quot;galaxy&quot;, &quot;solar-system&quot;, and &quot;planet&quot; would be confusing (something else already called &quot;planet&quot; that is very related, plus running into HtDP &quot;world&quot;, &quot;universe&quot;, etc.).  Before I&#39;d nitpick at that small level of issue, I&#39;d need the bigger questions above addressed, and then I&#39;d have to get practical experience with planet2 and comment on that level of issue.<br>
</blockquote><div><br></div><div>Although I wrote it, I&#39;m not attached to these particular bike shed colours. I&#39;d rather rename things to keep the wa than fight about why one analogy is good and one analogy is bad. All the names you&#39;ve mentioned have been given new labels from my first prototypes, and if people would like to submit patches to rename things that others like, I won&#39;t stand in the way.</div>
<div><br></div><div>Jay</div><div><br></div></div>-- <br>Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>&gt;<br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>&quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
</div>