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