Hi folks,
I am still waiting for a radically optimistic "wiki like" environment, where anybody (ok, say having at least the status of an apprentice on Squeak-People...) can change code of the current golden_and_shared_image anytime, ideally _always_ developing with it as the base for his (do we have a she on Squeak-People with at least apprentice status?) daily work.
A first rough description for a simple code-wiki architecture I'd like to use: ============= 1.) Some sandbox E.g. Accessing the file system from code that gets pushed into my image is a big no.
2.) Wiki features: Login, History, Changes, Rollback, Links To - Login with squeak-people account - Automatic versioning of methods and classes: When I save a method/ class in my browser, it gets stored as a new version in the central repository. (a tweaked squeaksource?) The new version is only pushed into other clients, when I release the package it resides in. (see 3.)). Other people can see it though if they browsed "versions" of the class/method. - History, changes and rollback of methods, classes and packages (or PackageInfo's as they somehow call them today) - Links to: Who needs that method, class, package
3.) Difference to wikis or Envy - A package knows whether it belongs to the _golden_and_shared_image or not - Packages do not get versioned, they only get released. As an airline company told me recently about my ticket: "Use it - or lose it" ;-) - Methods and classes get versioned automatically each time one changes/saves them, but they do not get released. - Methods and classes know whether they are part of a released package. - If a package gets released - it automatically gets a unique release id - it internally stores all release ids of all required packages (thus serving as some kind of loadable "config map" at the same time) - it gets pushed to every client using the shared environment (only if it belongs into the _golden_shared_image_ of course)
4.) A Notion of quality - Having the idea that any apprentice could push a new release of some package into my current image might naturally lead to more test awareness. One could think about being able to release a package only if -at least all changes (to start from somewhere) are also covered by a green test. -all tests of all _depending_ packages also still work, whether they are in the _golden and shared_ image or not -The more a package is down to the system, the more other packages will depend on it, and the higher the status (apprentice, journeyer or master) of the changing person must be. -Having the notion of package ownership the owner shall definitely at least automatically get a mail, if a new version of his/her package was released
PLEASE: Feel free to play with these ideas (or feel free to let your students play with it) or even implement them- I didn't even have time to write them down... ;-) There are some efforts to do sth like that in Croquet I have heard, but I don't know anything specific.... =================== Btw: Ward Cunningham is working for the "Eclipse committer community" and not for MS since Oct 2005:
"To date, the efforts of the Eclipse Foundation in support of the committer community have been primarily around providing infrastructure and process. However, a high functioning committer community is about more than just sharing servers and following a common process. A high functioning committer community is about collaboration and cooperation between the project silos. Although the Councils do an admirable job of co-ordinating the activities of the many Eclipse projects, what is needed is a culture of collaboration and cooperation. This is especially true today, as Eclipse grows rapidly with new projects and new committers.
To help cultivate this committer culture, Ward Cunningham is joining the Eclipse Foundation as Director, Committer Community Development. Ward's track record of invention in areas such as wikis, patterns and agile development are known worldwide. His current interests in open source and developing communities of developers are a perfect match for the work we need to do at Eclipse. Ward will lead the effort to create a more cohesive Eclipse committer community by working with developers in order to enhance Eclipse as "the place to be".
http://www.eclipse.org/org/press-release/20051019cunningham.html
So let's be faster than them :-)
Cheers,
Markus
On Mar 8, 2006, at 1:37 AM, Alan Grimes wrote:
Here's what I do when I find a bug in squeak:
- 90% of the time fix it myself without telling anyone, the rest I
can't fix and I try to report...
- I play around with squeak's built-in reporting system and get
yelled at to post it on Mantis instead...
- Scratch my head and wonder what a carnivorous insect has to do with
my bug...
Wait 4 days...
In the middle of a dream, while my mind is making random
associations, that mantis is actually squeak's bug tracking system.
- go to one of the well known squeak sites such as squeak.org looking
for a convenient link to the site. -- which fails...
- google the damn thing yet again... (except that I'm beyond
caring at this point...)
-- Don't let your schoolwork get in the way of your learning.