One last try (was: RE: Convincing a harvester (was on SqF list))

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu May 8 10:17:51 UTC 2003


Hi Martin!

Martin Wirblat <sql.mawi at t-link.de> wrote:
> Daniel Vainsencher <danielv at netvision.net.il> wrote on 07.05.2003 
> 22:19:30: 
> >What do *we* need to do to avoid our pool of packages from becoming
> >forks? as I said, we need for all images to share a "base". So the
> >derivative images should avoid patching that. We need our packages to
> >follow policies (which we'll need to invent). Part of which is that
> >packages are modules and it is very very bad manners for your package 
> >to patch another's code. Especially those of base. Distro's should 
> >have ZERO loose methods. It's all base + packages. That should mostly 
> >do the trick. 
> 
> Hi Daniel
> 
> I hope you didn't forget that we already agreed on having ONE release 
> which is going to be maintained and thoroughly tested AND an outer 
> circle of packages which reside on SM, which are not Squeak-official, 
> which may be experimental and which will not necessarily be maintained 
> etc. 

I don't think he has forgotten - and I have definitely not forgotten.
I think we should write this down on the Swiki btw.

> The release is expected to consist of three images in the next step: 
> Minimal, Basic and Full. Full is what today is the monolithic image. 
> These 3 images can and should be made up of packages and they are like 
> onion-skins. 

Right.
 
> To have something like TrueTypeTextStyle in the release, it must be 
> moved from the outer circle into there. After this inclusion the 
> package TTFS will be part of the official Squeak, the Squeak which is 
> to be released, and it will stay there in the future. 
> 
> To move it into the release a decision to do so is NEEDED.

Yes. And the Guides are the moderators that try to get the community to
take the decisions.
This is at least how it was *meant* to work. Let me say that again - we
weren't meant to *take* decisions but make sure *decisions were taken*.

But sure, perhaps that principle doesn't work in practice. Anyway, you
are right - the decision needs to be taken. And I think we got one too -
Daniel fought well but in the end I would say that most were in favour
of bringing it in.

> Your magic trick with which you think you can 'avoid forking' will not 
> change this. You said the guides duty is not to have a vision for 
> Squeak and some guides may not be interested that much in Multimedia 
> that they want to take on such a decision and that people should 
> 'sell' their wish of inclusion to the guides. I think not the code of 
> the one who _sells best_ should be included, the _best code_ or the 
> _most needed function_ has to be chosen. 

I don't think there is a difference. If a function is sorely needed it
sells. Just playing with words.

> It seems to be that Squeak lacks someone who wants to make such 
> decisions and is able to do so. Perhaps it is not appropriate for me 
> to make such a proposal, but after all this discussion in this list, I 
> must say I think Andreas ( along with Doug ) should make these 
> decisions. Of course with previous discussions with the rest of the 
> world. 

Eh, well - to just throw out two names and then think the problem is
solved feels a little naive to me. :-)

I would instead like us to find a little process - don't get scared by
the word. For example (just an example) - we could designate one or two
Guides to only be responsible for making sure decisions are taken and
also responsible for maintaining a list of those decisions and their
status.

The exact procedure for taking the decisions could include a very simple
"form" that needs to be filled out and posted with a special tag. I know
other people have described similar approaches earlier on this list
inspired by the Pythonians etc - I don't claim fame to these ideas.

A PROPosal could simply have a date, a description, who proposed it and
a motivation. That would be enough formalia.

And further how the decision is taken - through discussions on the list
and then a simple "feeling of the gut" by the Guide. Or through some
form of vote. That could be left up to the Guides taking on this
"decision guiding role".

> A last word about combinations of packages and forking. The fact that 
> quite some people on the list feel unsure about this trend of 
> modularization should make you and Göran a bit less optimistic about 
> the 'magic' of loadscripts and friends. As you hopefully remember I 

I am optimistic but I still respect the problems ahead.

> already wrote some posts regarding this. Therefore only this: It is 
> much easier to develop a monolithic image than to have many packages 
> which are developed isolated, not the other way round. Given the 
> problems of the image today we should really be humble ( at least in 
> the beginning :-) 

I agree in some respects but not in all. It is easier to have it in a
monolithic image because you can use senders of, references to etc. and
you can browse how code is used.

But on the other hand - with packages you will be forced to have better
control over your dependencies and you also get to choose development
model. And you can more easily control patches and changes sent to you
because it will only be the stuff that is really meant for your package.
In other words - you don't get drowned by the noice of all the other
development going on in the rest of all the packages.

So it isn't a black and white picture IMHO. But it does need more tool
support - the crossreferencing would be really cool to be able to do
through an index database.

If someone could take Magma and build a model that only keeps track of
class references, message sends and implementors. And then let that
model "scan" all packages available on SM and build the indexes it would
be really slick to be able to send "queries" to that model. A sortof
global "senders of". It could perhaps even contain the source somehow so
you could browse the sending methods "by remote".

Blablabla...
 
> regards
> Martin

regards, Göran



More information about the Squeak-dev mailing list