Some subjective requirements for a radically optimistic "Code-Wiki"
(was: Re: bugs on mantis: who assigns them ?)
Markus Gaelli
gaelli at emergent.de
Wed Mar 8 15:05:12 UTC 2006
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:
>
> 1. 90% of the time fix it myself without telling anyone, the rest I
> can't fix and I try to report...
>
> 2. I play around with squeak's built-in reporting system and get
> yelled
> at to post it on Mantis instead...
>
> 3. Scratch my head and wonder what a carnivorous insect has to do with
> my bug...
>
> 4. Wait 4 days...
>
> 5. In the middle of a dream, while my mind is making random
> associations, that mantis is actually squeak's bug tracking system.
>
> 6. go to one of the well known squeak sites such as squeak.org looking
> for a convenient link to the site. -- which fails...
>
> 7. 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.
>
> http://users.rcn.com/alangrimes/
>
More information about the Squeak-dev
mailing list
|