Andrew, Karl and Stan raised very good questions.  In the meantime, other
people perhaps also responded, but I'll start to answer these questions.  I
must admit that I wasn't as clear as I'd have wished - my usual problem
when I'm writing something while still figuring out my points.

To sumarize my concerns: I'm not against a swiki but in favor of a well
maintained central list.  This allows one to look just at one place without
the need to search different sources for source code.  A dedicated
maintainer will hopefully also guarantee up-to-date and complete information.

>Why do you (Stefan) not like the swiki for this task?  I like the
>swiki because it is simple.

Let me try to explain what I dislike about wikis in general.  They're
chaotic and unstructured.  This is sometimes a good thing (please note:
chaotic != evil, for a good definition of chaos please see Moorcocks Elric
books), but most often, it's difficult to find the information, to detect
updates or to notice changes.  I know, there're some ways already but
still, it's difficult to assure that pages doesn't duplicate data (perhaps
even with contradicting contents), that certain pages are cept up to date
and that links lead to useful contents.

A technical disadvantage is that you have to be online while writing
something.  Information is also broken down in very small chunks so you
cannot download useful parts and browse them offline.

For me, a swiki isn't simple as I have to go online and stay online while
doing the research.  I'd prefer to send some email and subscribe for some
web pages.  I most times got lost in swikis, perhaps it's only the feeling
of getting lost because its difficult to see from where you came to that
new page - and why.  Information isn't structured and there's always the
gnawing feeling of missing the most important pages.

>url1, url2.  And I like the swiki because it is fast. If FMP breaks in

It's not faster than a cgi-based database like for example freshmeat.net or
tucows.com.  Theses services however hold back submissions until they
checked them out personally.  One could argue about whether this is useful
for Squeak or not.

>squeak version 3.0, you fix it and notify the swiki, then I see your
>fix immediately. 

Yes and no.  You see the fix and nobody else is notified that this fix is
available now.  I don't think that most people behave the way you described
it.  If FMP is broken, I probably simple go along, perhaps being a bit
anoyed about that Author not maintaining his or her software.  But only
very few people would try to fix it.  So that speed isn't needed.

I think, the usual way for sending in fixes is to contact the original
author or current maintainer so that she or he has the final word.
Otherwise, we get too many branches.

>I don't have to wait for your fix to propagate
>through middlemen at the central registry, or to be blessed by Bob.

I think, the blessing is very important.  Just think about a Linux kernel
that isn't "blessed" by Linus Torwald.  You wouldn't trust it in the same
way as now.  It's also a kind of kindness to not ignore the original author
IMHO.

>I think the problems you describe are important areas with room for
>improvement, but I'm not yet convinced that replacing the swiki with a
>central repository is the best way to solve all of them.

Me too.  I mainly wrote the text to work towards a solution, but to simple
present one.   In the meantime, I think, perhaps all we need is one or a
few volunteers who want to maintain a certain number of swiki pages on a
regular (at best daily) base.

>You gave three examples where bugs were solved twice. I am not
>optimistic that a new central repository would solve this; we already
>have a repository at http://swiki.gsug.org:8080/SQFIXES/. How would
>the new repository be better?

It wouldn't be automatic, it would be human-controlled.  Anybody could tag
his email as [ENH] and so get into the SQFIXES list (as I understand it)
but a maintainer could undo this.

>You also complained that some enhancements were ignored. There are two
>very different things you might mean here; you might mean that the
>enhancements were not added to the official squeak image, or you might
>mean that these enhancements were not used by any other squeakers. If
>you mean the former, well, some enhancements must be ignored if the
>core system is to remain small and understandable.

So but Tetris, IRC or some (really cool, I've to admit) speach synthesesis
belongs to that small core image?! ;-) I understand and subscribe your
statement but this rule has more exceptions that that it was followed.  And
fixing some minor glitches to the system never adds so much.

I was talking about added to the base image, BTW, as I've no idea whether
anybody really tries out all that fixes or whether everybody simply skips
that emails and waits for the next official image.

>weakness. How do you think the enhancements could be made easier to
>find? Who should we copy? CTAN? Red Hat?

What's CTAN?  RedHat (or SuSE) looks like a good idea IMHO.  I think, the
Perl community also has a central archive which might be something worth
copying.


>You complained that we cannot tell what version of squeak a given
>piece of code works in. I agree, we haven't done this very well. I
>have a suggestion for how we could do better; when we try an old
>package in a new image and it doesn't work for us, we should add a
>note to that effect on the swiki. (Even better, we should fix it, but
>I'll settle for what I can get. :-)) The swiki would be more up to
>date if we would all use it more often.

Yes, I'd subscribe that that last statement.  But instead of believing in
the people, I started to wonder whether the tool is right. 

Sidenote:  What's about adding a concept of template to swiki-pages so that
it's easier to fill out forms for things like bug reports or fix submissions?

>You mention that many parts of squeak need refactoring, but you fear
>to do this because you fear your work will be ignored. I think
>PluggableWebServer needed refactoring. I think Bolot refactored it,
>producing a class of a different name with similar functionality.  I'm
>using Bolot's work. Have less fear :-).

I've no fear in changeing anything I dislike in my image but I'm unhappy
about the idea that there're ten more people like me, all doing the same
work.  I didn't know that Bolot did that refactoring.  Did he mention that
on the swiki or in the list?  Did you know that I refactored the
ButtonMorph classes?  Who else did what?  Will a swiki really help here?

As long as the community is small enough that everybody knows everybody
else personally (or at least via email), a common consense might help.  But
I'm thinking about a larger community.  Here, I think, you need more formal
methods.  And a community size of Perl or Python, or even Java should be
our goal.

>Finally, you mention that code is spread all over the internet, but I
>can't really see that http://swiki.gsug.org:8080/SQFIXES/ works any
>the worse for that.

I didn't really thought about that server.  You're right.

>Although I guess I disagreed a lot of your points, I do agree with you
>that these are important issues. The better a job we can do of making

I'm glad you disagree because otherwise, we cannot discuss :-)

>unofficial contributions easy to find and use, the more tested and
>refined these unofficial contributions will become.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.