Ah, I missed something in your message. I am recommending Monticello for contributions of in-image documentation, but I am *not* recommending Monticello for *distribution* of in-image documentation. For distribution, I'm less particular, but I think something like SqueakMap would be a great choice. I think having the bit of plumbing necessary to load, read, and edit documentation in the standard image would be fine, but I don't think we'd want to include the actual docs by default (maybe just a menu item to install the documentation, or some such thing.) I would expect that the aforementioned plumbing would be unloaded with #unloadAllKnownPackages.<div>
<br></div><div>Hope that clarifies my position a bit.<br><br><div class="gmail_quote">On Fri, Apr 30, 2010 at 3:35 PM, Ken Causey <span dir="ltr"><<a href="mailto:ken@kencausey.com">ken@kencausey.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> -------- Original Message --------<br>
> Subject: Re: [squeak-dev] [documentation] HelpSystem, revision control,<br>
> and process<br>
</div><div class="im">> From: Ian Trudel <<a href="mailto:ian.trudel@gmail.com">ian.trudel@gmail.com</a>><br>
> Date: Fri, April 30, 2010 5:20 pm<br>
> To: The general-purpose Squeak developers list<br>
> <<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>><br>
><br>
><br>
</div><div class="im">> Quick question, Ken (and Casey).<br>
><br>
> How will the core related documentation will be transfered to the core<br>
> image assuming what you wrote will define our process? HelpSystem<br>
> includes classes and methods comments.<br>
><br>
> Ian.<br>
<br>
</div>Well, this is exactly why I have that leading sentence. ;) I have no<br>
idea how content distribution (which is what I assume you are asking<br>
about) is meant to work in HelpSystem. I have to assume from Casey's<br>
question that it can be distributed in a mcz. As such it can be<br>
retrieved via any method desired and from any location. What triggers<br>
loading any particular content? I don't know, is there meant to be a<br>
catalog something like SqueakMap or Package Universes? Or is help for a<br>
particular package an optional dependency? Clearly, as I stated, I have<br>
no end of questions.<br>
<font color="#888888"><br>
Ken<br>
</font><div><div></div><div class="h5"><br>
> 2010/4/30 Ken Causey <<a href="mailto:ken@kencausey.com">ken@kencausey.com</a>>:<br>
> > I haven't been following the HelpSystem discussion very closely so there<br>
> > is no limit to what I don't know on this subject. That said I would be<br>
> > perfectly happy setting up a HelpSystem repository on <a href="http://source.squeak.org" target="_blank">source.squeak.org</a>.<br>
> ><br>
> > In general I feel we need to start limiting the contents of the trunk<br>
> > repository to those packages that compose 'core' Squeak and start<br>
> > considering add-ons used to build 'basic' Squeak as separate packages<br>
> > installed into 'core'. I'm assuming that HelpSystem is something we<br>
> > would want to include in a 'basic' image, but not a 'core' image. (Of<br>
> > course a 'core' ZIP might include ready to load optional packages<br>
> > including HelpSystem.)<br>
> ><br>
> > Ken<br>
> ><br>
> >> -------- Original Message --------<br>
> >> Subject: [squeak-dev] [documentation] HelpSystem, revision control, and<br>
> >> process<br>
> >> From: Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>><br>
> >> Date: Fri, April 30, 2010 3:22 pm<br>
> >> To: The general-purpose Squeak developers list<br>
> >> <<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>><br>
> >><br>
> >><br>
> >> Folks,<br>
> >><br>
> >> I'd like to get a process going around HelpSystem. It doesn't have to be a<br>
> >> perfect process. We can tweak it as we go.<br>
> >><br>
> >> How do people feel about having help in the Trunk? It'll allow us to<br>
> >> document things right along side of our software development.<br>
> >><br>
> >> One thing worth noting: we can have our HelpSystem "book" in Trunk without<br>
> >> necessarily having HelpSystem itself in the Trunk; however, if we do it that<br>
> >> way, we run the risk of changes in HelpSystem on SqueakSource making our<br>
> >> help content impossible to load. I think having both in the Trunk is a<br>
> >> really good idea.<br>
> >><br>
> >> If folks aren't comfortable with having some documentation and HelpSystem in<br>
> >> Trunk, I'd like to propose opening up a 'docs' SS repository on<br>
> >> <a href="http://source.squeak.org" target="_blank">source.squeak.org</a>. We'd lose the ability to track the evolution of our docs<br>
> >> in the context of the evolution of Squeak, but we'd still have the keys to<br>
> >> the kingdom (license, code, content.)<br>
> >><br>
> >> I'd rather not go with <a href="http://squeaksource.com" target="_blank">squeaksource.com</a>, as I'd like to think that our docs<br>
> >> should live with the other things on <a href="http://squeak.org" target="_blank">squeak.org</a>.<br>
> >><br>
> >> As always, feedback is appreciated.<br>
> >><br>
> >> --<br>
> >> Casey Ransberger<hr><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> <a href="http://mecenia.blogspot.com/" target="_blank">http://mecenia.blogspot.com/</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>