Torsten,

Sake/Packages does the same thing as Metacello (40 classes) afaik in 1  
class.

One for implementing the Packaging behaviour on top of Sake (2 main  
classes, and few Signals). Then you have as many classes as you need  
to provide suites of Package definitions, i.e. one for Squeak3.10 and  
one for SqueakPharo.

>> Does it track Universes package definitions?

Because that is what we are already using to indicate what works where  
within the squeak community.

> No, why should it. It's a package management for Monticello

So was Universes, using the hard work of others who had been filling  
up Universes with data is a good thing no?

> and as I already said it is not limited to Squeak and its derivates.

That is why Sake/Packages is such a minimal idea, it should port easily.

> Universe is Squeak only, you wont find it for instance on Gemstone.

But Gemstone uses MC, and universe defines dependencies between MC  
packages, which GS may find useful. So porting S/P to gemstone would  
have been the quickest way to port universes data too.

Due to Gemstone people, not asking the question "I wonder if someone  
has done this before, in a portable way."

> Metacellos goal is not to rival with Bob/Sake or try to push
> packages or Mantis fixes into any image derivate out there

I have no idea what you are talking about in this paragraph, S/P is a  
package management system simple as. However there is one key  
difference. The package definitions are maintained by the user  
community not the package developers. This means that it is more  
likely to work for you, or be made workable for you if you are using a  
context that is different to the package developer, you can also add a  
fix to the definition if a package needs it. This captures the  
information that a fix is needed in your context.

Sake/Packages is the simplest possible package management system built  
upon the dependency ordering abilities provided by Sake.

> Seaside and Metacello are currently working well enough
> to build upon.

Seaside28 and Sake/Packages was working well enough when I wrote it 2  
years ago.

Load LPF,
Installer install: 'Packages'.
Installer sake install: 'Seaside'.

or something like that.

And I showed Seaside3.0 loading showing off MC1.5 atomic loading and  
unloading 7 months ago.
Check out the video on vimeo.

http://www.vimeo.com/groups/squeak/videos/5434330

The seaside3.0 sake/packages definitions were provided by builder.st,  
but needed some mangling. Efforts to ask lukas to change things fell  
on deaf ears and I don't actually use seaside 3 yet, if ever.

> They are open, maintained and one can easily participate.

In your opinion, I gave up trying to contribute to seaside years ago.  
Hence

www.squeaksource.com/Seaside28Jetsam and
www.squeaksource.com/Beach

> Should I rather invest my time into unmaintained code?

I maintain code that I use. I use seaside.

I have ceased coding for the benefit of fictional others, who aren't  
really there, simply because if I do, divert the time and the energy I  
starve.

> Metacello
> (as well as Seaside) just work and are accessible, supported and
> adopted. So there must be a difference, no ?

Yes the difference is, S/P was there first, is simpler, it works too.  
It might not be as flashy as Metacello in some respects, but any short  
fall can be made up relatively easily.

> What about Bob/Sake? With all your actions

My actions? There is a concept known within abuse counselling. "When  
you point out a problem, this does not make you the problem." and that  
"when someone uses the fact that you point out a problem to turn you  
into the problem, this is abusive."

So please stop abusing me.

I point out the problem that the board acted wrongly, this does not  
make me the problem.
I point out that all the important decisions being made in these  
communities are seemingly isolationist, bespoke, and counter  
integration.

> I dont think it will
> have a bright future, even when you open the repo (which is still
> access restricted).

I don't think it will have a great future either, but that is not for  
want of trying, and this is more a function of the way the community  
appears to work in its politics, than any technical reasons.

>
>> Gofer, a complex heirarhcy for four actual methods which do
>> anything
>
> same comment as on top of this mail

Gofer - ensuring MC loads cleanly... how about fixing MC. Oh you cant  
there are 5 forks of it. MC1.5 has some of the functionality of gofer.

>> if you build anything on lukas' stuff be preopared to find
>> the whole infrastructure changing under you in a weekend, he wont  
>> even
>> look at any thing you offer as an addon.
>
> Nonsense, there is an active list with discussions - anyone can
> participate. You can open bugs, get fixes included, ...

I can show you examples of one line fixes still sitting in the repo.

> The framework is well written, there is documentation (even with a

Lukas has never loaded Pier-Magma one of the earliest addons.

He changed the parser from SmaCC to a hand crafted one over night,  
when I had projects depending on the SmaCC one.

> book) and meanwhile ported and used in other Smalltalks too.
> Lukas takes care even to beginners questions. Never had a problem
> with him.

> When I offer something it either gets included or I can provide
> it as addons (like the JQueryWidgetBox I did).

It only a matter of time.

>  So again ... what is your point. You sell yourself as the miracle  
> healer
> who was interrupted right before he was able to cure us from all  
> illness.
> We now also know that your approach would have done it better than  
> anything
> other. Then take this last step (another week?) to finish it and

I am not saying any of this.

What I am saying is, that there is no excuse whatsovever for treating  
people like shit, period.

I dont care how good trunk is, and I dont care how good Andreas is he  
has blood on its hands. "metaphorically speaking"

> convince people to adopt it.

I wrote a proposal for the board 2/3 years ago. I wont compete. The  
community needs to work in collaboration, and valuing the  
contributions of others, with planning and thinking, not by brute  
force, overriding, and bullying.

Hopefully S/P is a better fit for Cuis due to its simplicity.

Keith