Hi Roel and you all down there in Bern!

Roel Wuyts roel.wuyts@iam.unibe.ch wrote:

Hi Goran, before mentioning anything on the list I'd like to discuss some views we have here on how the decentralization of responsibility of Squeak could be done.

Sure, I took the liberty of CCing this onto the SqF list since that is "Guide territory".

To make it concrete, we are deciding whether or not we will propose to become the responsibles for the meta-programming/reflection part in Squeak (ClassBuilder, ...). [Note that this is about base image parts, not about 'optional' things like StarBrowser, etc.] Our motivation is

Right, sounds very good to me. You are pretty strong in that department and you are also driving much of the development there currently.

that in order for some of our research, we need to change this anyway. So we might as well give this back to the community. However, in order for us to do this, we think that some structure should be put in place first:

• there has to be a clear boundary about what the part of Squeak

contains that you become responsible for.

Right. For packages in general it is pretty obvious but for parts that perhaps never will move out from the kernel (like the parts you are talking about) the boundaries need to be "declared" somewhere.

• this part of the system needs to be fully documented with unit tests

(at least) or whatever other documentation is needed otherwise (I take a pragmatic view in this whole documentation discussion).

Right.

• the unit tests have to be available for download via Squeakmap etc.

so that anybody can try them.

Yes, those are indeed suitable as one or more packages on SqueakMap. And frankly, we can register the core parts as packages too - for "mapping" reasons.

It is good to see maintainer, homepage, version etc even if the package itself really can't be broken out of the core image. And later I am envisioning stuff like linking bugreports, updates etc to the packages so having a package registration is in itself good.

• all changes to the part that you are responsible for, can only be

approved by you.

Yes, that is the idea with responsibility! :-)

• anybody who wants to update something in your part, has to download

the unit tests, make the change, and can only submit a patch that runs with these tests. Then the maintainer has the responsibility to include this patch, after some more reviewing internally, or reject it.

Now you are discussing the development process in detail and even if I sympathize with the goals there are many different ways of doing this in practice. For example, the new Harvesting tool was intended to be "package aware" and tus have multiple "production lines" where FIXes/ENHs etc are lined up for review, test, modification and eventually inclusion into the package.

But anyway, I agree. If there are unit tests available, patches will only be considered if they are green with them. And I also agree that the maintainer has a responsibility to consider all contributions.

• bugs are submitted as failing testcases (ideally). Or they can also

be submitted in text, but only in rare cases (very hard setup, etc.).

Guidelines, sure.

New tests have to be added that reflect the fixed bug.

Right.

PS: This mail is from all of us in Bern. But I was chosen as communication medium :-) I hope it is a bit clear what we mean :-)

PS2: We are still deciding what we will do, but a bunch of guidelines like this should be put in place anyway.

PS3: Feel free to distribute this mail wherever you think it is useful.

I am all in favour of: - Laying out the "rules" for how we distribute "maintainership". - Actually starting to dish out parts.

As we are all aware of - the social mechanisms within the community are very important to take into account. Therefore I think it is important that we agree on how this "maintainership" is decided and what responsibilities comes with it. But it should of course still be a "fun thing to do" - after all, we are driven by the fun of it all in the end. :-)

regards, Göran