Hi Torsten -

Thanks for the thoughtful response. It'll take a little to respond to 
the points individually, so apologies for the length of the response.

First of all, nothing is "decided" yet. I've made a proposal, people 
appear to like it, so we can start a phase of experimentation. If the 
experimentation works out, we can add this for 4.2 and if not, we'll see 
what's lacking and how to fix it.

On 5/17/2010 5:14 AM, Torsten Bergmann wrote:
> I tried to follow the discussion on both lists regarding supported packages and how/where to manage them by using Metacello. I can not give complete feedback
> since I go with Göran here who said "I need to read your thoughts once more
> before giving proper feedback." and I think we all should take the time to
> think about all the implications the different approaches have.

Absolutely. One thing that took me by surprise is the response in the 
Pharo world. Given that this is a proposal for Squeak I thought that the 
response would at most be "see, we told you so". Instead it appears to 
be ... well, I'm actually not exactly sure. Seems like a mixture of 
feeling threatened and NIH.

If you look at it objectively, my proposal is extremely similar to what 
Pharo uses, and I've explicitly mentioned that it was inspired by 
Pharo's use of MetacelloRepository. Outside of the community packages 
aspect, pretty much the only differences are:
1) Whether to use one configuration per package or not.
2) Whether configurations are preloaded in the image.
That's about it. I really fail to see what the big hiatus is about.

If you do decide to answer the above in a particular way (namely the way 
I've proposed it) you also gain a few additional advantages such as 
knowing that the code you have is trustworthy and such as having an 
easier time building a UI. But that's about it.

> With this discussion we set up the base for the future of package maintenance
> but also for collaboration amongst the communities, how images are built, ...!
>
> I'm sure we all want to blur the line between in and out of the (whatever) image
> and share/reuse as many code/packages as possible within the broader community
> (Squeak, Pharo, Cuis, Gemstone, ...). So:
>
> Goal Nr. 1 is: if it is not in my environment then just load it.
> Goal Nr. 2 is: if it is loaded it should work in my environment since it brings
>                 in anything it needs to work

 From my perspective that definition of the problem is a bit 
superficial. There's a reason why I called this post "community 
supported packages" and not just "package management" because we also 
need to work out a way to support packages in the long term. I agree 
that the above two goals are intrinsic part of what I'm talking about 
but there are other aspects to it which are just as important.

We are a small community so we do need to set an artificial boundary on 
what we support. If we support "everything" we end up supporting 
nothing, which is what we see in Universes and Squeakmap. So an 
inseparable part of my proposal is an explicit community contract; there 
are certain requirements and benefits that we aim to gain by 
coordinating on the package maintenance. I *want* to separate projects 
like Omnibrowser and HelpSysstem from random garbage so commonly found 
on Squeakmap and Universes. It's because the people around it care and 
it's because of that that I want to have an explicit contract that 
basically says "you care, we care". No it's not free to become a 
community supported package, but it's *because* it's not free that it's 
also valuable.

(there are several other aspects to it which I just deleted because 
otherwise this post will get positively exhaustive and really all I'm 
saying is that for me there's a bit more to it then the individual's 
desire to install some code ;-)

> Currently the discussion and actions seem to focus on where to put the
> configurations (into the image vs. in repositories per version). I'm in favour
> of the latter since that is easier to handle and share between platforms
> while having them in the image would limit people who work on various
> platforms, it would not scale and eat more resources for maintenance.

Nothing prevents us from doing just that if we find it preferable. I 
agree that updating is a little easier if you do it externally but then 
again, I feel this is part of what the community contract implies. Is it 
really asked too much to post an update to the inbox if you make a new 
version?

On the other hand, having it in-image makes it easier to build a UI and 
it also provides implicit structuring simply because we can utilize 
system categories to provide a first level of structure. So under 
"Configurations-Network" you would find the WebClient config next to 
other network related configs. Simple and straightforward.

> My fear is also that if you have the configurations within the image then
> we all will end up with something similar to the unmaintained SqueakMap
> registrations. With external repos we can also feed CI-Tools (Hudson build
> server, ...)

The issues in both Squeakmap and Universes originated from people using 
them for many different versions. The same appears to be happening in 
Pharo's Metacello repository. There are some configs that work only in 
Pharo 1.0 and some that work only in 1.1. That is the root cause for the 
problems both Squeakmap and Universes share. And as Squeakmap has 
proven, the other problem is that not all software is created equally. 
At some point you need to make a decision of what you consider 
"supported" (and consequently try to make work for the release) and what 
you consider "third party" and none of your business.

There are of course other ways of dealing with that from what I am 
proposing. Having it in-image however, makes the status very explicit. 
There's no doubt about what is considered supported and when one 
achieves (or loses) that status. If it's in, it's supported, if it's 
out, it's not. Plus it uses our community processes for development so 
if there's an update for a package you'll find out simply by virtue of 
seeing the commit message.

> But thats not the main question. Even if Squeak decides to have the configurations
> "in-image" and Pharo decides for external configs one can mix them:
> An in-image ConfigurationOfMyApp just loads the ConfigurationOfMyAppExternal
> where the last one is maintained in an external repo and the internal
> config is for convenience to just load it.

Yes, that would be another fine option.

> Lets think about the implications for anything above the virtual machine:
>
[... snip ...]
>
> If Squeak jumps on the Metacello config bandwagon it may also have to think about
> jumping onto the "small core + external packages" model. At least to me
> this would be the next logical step.

Heh, where have you been over the last year? :-) If there's one thing 
where there has been absolute agreement on it's just that. But it's a 
matter of when to do it and how to do it - we don't just want to create 
bit rot, we want to keep supporting the packages we choose to support. 
And that requires some agreement on how the larger picture of 
"supporting" packages looks like. And that's where we get into community 
supported packages and the reason why it's not "just" a Metacello issue.

> This leads to several questions:
>
>    - could this small core could be the same for all of us - especially since
>      we currently fix stuff in Cuis, Squeak and Pharo mostly the same way

Interesting thought. Is that perhaps the root of feeling threatened? In 
any case, it's an interesting question that deserves some thought. I'd 
say there are three questions to answer:

* Does such a process requires some (or all?) participants to give up 
their original identity?

* What would the development process look like?

* How would a conflict resolution process look like? (and by conflicts I 
don't mean package conflicts :-)

If anyone is seriously thinking about this (I'm not) you might want to 
approach it by staking out an area that's part of all the images and 
that has relatively few changes, like the Graphics package. I'd be 
curious what people come with about how to address the resulting questions.

Cheers,
   - Andreas