[Squeakfoundation]Re: Taking control of parts of Squeak

[goran.hultgren at bluefish.se]

Hi Roel and you all down there in Bern!

Roel Wuyts <roel.wuyts at 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