Stefan Matthias Aust <sma at 3plus4.de> wrote:
> Daniel,
> 
> You raised some very good points.  Actually, the idea of multiple update 
> servers was already mentioned by Torge Husfeld a few months ago, I 
> think.  At least he told me he'd write about that idea on the list.
This is not a new topic, but one I saw as unresolved...

> IMHO the core problem is the still monolithic all-inclusive image that is 
> [create a "standard" base one can expect]
Seems to me Squeak is too dynamic for that, and so by intention.
 
> Multiple update servers can help - but they can also make things worse.  At 
> the moment, it's often tricky to make different updates of different 
> persons works (which otherwise would introduce old code again) and also 
> synchronize this with whatever projects the SqC is working on.
I don't know how to make integration easy. But we can make sure the
transmission is trivial, which it surely isn't now. Maybe we can help
the integration some, too, by noting conflicts with methods that
changed. For example, if the server notes that my code came from a
SqC2098|Celeste0031|Scamper0008 image, and I change a method that's been
modified by SqC2134, and the two are indeed different, it should alert
me before accepting the code as an update. Maybe even reject it and make
update and integrate first.

Well, that's mechanics...

> >wrestle with your attached or web-posted changesets. It's never clear if
> 
> Of course, you could simply declare version X with updates Y as your base 
> system and life with that.  Perhaps you don't need the latest keyboard 
> enhancement or the Scamper-fix of the day.
Sure, and then you send silly bug reports to the list, of things that
have recently been fixed, with detailed explanations on how to reproduce
them... ;-)

> >the second changeset you send, fixing a bug, is incremental or replaces
> >your original post. And if the project has multiple participants? don't
> >even ask.
> Make the Package Browser your friend.  I inspect every piece of source in 
> my beloved brown companion before I dare to file it in.  It's a nice tool 
> to determine what parts of the system the included code will change.
Sure, but it's another barrier to having your code tried out...

> >And on top of it all, when the new, the great, the
> >non-backwards-compatible 3.0 comes out, you just know it'll all go to
> >the great bitbin in the sky. Unless - unless your project is good, and
> >nice, and oh, so, very compatible, for if all that is true, and you are
> >most lucky, well then, then I say- you might just have your project
> >integrated into the base image...
> 
> Project maintainer are IMHO responsible for updating their code to the next 
> version, if they like.  Otherwise, if it's a kind of stand alone 
> application like a swiki, who exactly cares which version of Squeak it 
> needs - as long as that version already works without errors.
I'm assuming one updates the project - the problem is that all your
users have cleaned the slate with the new image and now have to start
digging for your code again. Except if it's SqC code. Or if you have an
project update stream.

> >And that's the jackpot. That's like getting tenure. It's like, a
> >government pension. Your name (and your code) will be struck into one of
> 
> I'm afraid, you've the work idea here...  As an independent project 
> maintainer you've the freedom of choice - whether you want to upgrade or 
> not - if it's official, Dan and the other SqC guys will convince (in other 
> words politely force) you to do the update work :-)
Well, I don't expect anyone to update/integrate my code for me - just
the chance to get it effortlessly into willing users' image again after
I've made it compatible.

> I imagine a kind of sourceforge for Squeak.  You can set of a swiki page 
> for your project, establish an update channel and then work together with 
> other people on that project, posting updates and allowing anymore (or not 
> - one could easily add password protection) to download the project to try 
> it out.
Too much work. I'm extreme in few things as I am in my laziness. The way
I see it - creating a project should be as easy and quick as mailing a
changeset. Publishing a update - sending another changeset with the same
name.

> However, as Bert already mentioned, with over 1000 updates it's getting 
> difficult to startup from ground.  This problem could also affect other 
> projects.  So I'd like to see a way to somehow accumulate changesets, 
> building larger versions people could download if they want to start from 
> scratch.   Although - if you start with CVS, you also have to download 
> everything at the first time - perhaps not that of a disadvantage.
Didn't understand this paragraph. Please explain?

Daniel