I haven't been following the HelpSystem discussion very closely so there is no limit to what I don't know on this subject. That said I would be perfectly happy setting up a HelpSystem repository on source.squeak.org.
In general I feel we need to start limiting the contents of the trunk repository to those packages that compose 'core' Squeak and start considering add-ons used to build 'basic' Squeak as separate packages installed into 'core'. I'm assuming that HelpSystem is something we would want to include in a 'basic' image, but not a 'core' image. (Of course a 'core' ZIP might include ready to load optional packages including HelpSystem.)
Ken
-------- Original Message -------- Subject: [squeak-dev] [documentation] HelpSystem, revision control, and process From: Casey Ransberger casey.obrien.r@gmail.com Date: Fri, April 30, 2010 3:22 pm To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Folks,
I'd like to get a process going around HelpSystem. It doesn't have to be a perfect process. We can tweak it as we go.
How do people feel about having help in the Trunk? It'll allow us to document things right along side of our software development.
One thing worth noting: we can have our HelpSystem "book" in Trunk without necessarily having HelpSystem itself in the Trunk; however, if we do it that way, we run the risk of changes in HelpSystem on SqueakSource making our help content impossible to load. I think having both in the Trunk is a really good idea.
If folks aren't comfortable with having some documentation and HelpSystem in Trunk, I'd like to propose opening up a 'docs' SS repository on source.squeak.org. We'd lose the ability to track the evolution of our docs in the context of the evolution of Squeak, but we'd still have the keys to the kingdom (license, code, content.)
I'd rather not go with squeaksource.com, as I'd like to think that our docs should live with the other things on squeak.org.
As always, feedback is appreciated.
-- Casey Ransberger<hr>
Quick question, Ken (and Casey).
How will the core related documentation will be transfered to the core image assuming what you wrote will define our process? HelpSystem includes classes and methods comments.
Ian.
2010/4/30 Ken Causey ken@kencausey.com:
I haven't been following the HelpSystem discussion very closely so there is no limit to what I don't know on this subject. That said I would be perfectly happy setting up a HelpSystem repository on source.squeak.org.
In general I feel we need to start limiting the contents of the trunk repository to those packages that compose 'core' Squeak and start considering add-ons used to build 'basic' Squeak as separate packages installed into 'core'. I'm assuming that HelpSystem is something we would want to include in a 'basic' image, but not a 'core' image. (Of course a 'core' ZIP might include ready to load optional packages including HelpSystem.)
Ken
-------- Original Message -------- Subject: [squeak-dev] [documentation] HelpSystem, revision control, and process From: Casey Ransberger casey.obrien.r@gmail.com Date: Fri, April 30, 2010 3:22 pm To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Folks,
I'd like to get a process going around HelpSystem. It doesn't have to be a perfect process. We can tweak it as we go.
How do people feel about having help in the Trunk? It'll allow us to document things right along side of our software development.
One thing worth noting: we can have our HelpSystem "book" in Trunk without necessarily having HelpSystem itself in the Trunk; however, if we do it that way, we run the risk of changes in HelpSystem on SqueakSource making our help content impossible to load. I think having both in the Trunk is a really good idea.
If folks aren't comfortable with having some documentation and HelpSystem in Trunk, I'd like to propose opening up a 'docs' SS repository on source.squeak.org. We'd lose the ability to track the evolution of our docs in the context of the evolution of Squeak, but we'd still have the keys to the kingdom (license, code, content.)
I'd rather not go with squeaksource.com, as I'd like to think that our docs should live with the other things on squeak.org.
As always, feedback is appreciated.
-- Casey Ransberger<hr>
On 01.05.2010, at 00:10, "Ken Causey" ken@kencausey.com wrote:
In general I feel we need to start limiting the contents of the trunk repository to those packages that compose 'core' Squeak and start considering add-ons used to build 'basic' Squeak as separate packages installed into 'core'. I'm assuming that HelpSystem is something we would want to include in a 'basic' image, but not a 'core' image. (Of course a 'core' ZIP might include ready to load optional packages including HelpSystem.)
Ken
I still would put these into the trunk repo. This is independent of whether to put them into a release image or ship them externally.
There is, however, some need to optimize or clean out the repo. It feels ever slower. How about moving out all package versions prior to the 4.1 release?
- Bert -
There is an additional advantage to use the trunk: we can capitalize over the current success of the trunk. Plus, documentation commits will be reported (as other commits) and it's a great way to show how much positive energy is sunken in Squeak.
Ian.
squeak-dev@lists.squeakfoundation.org