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

    I took the liberty of forwarding this onto squeak-dev. since
    that is the main territory. ;-)

    Cheers,

    PhiHo.

----- Original Message -----
From: <goran.hultgren at bluefish.se>
To: "Roel Wuyts" <roel.wuyts at iam.unibe.ch>
Cc: <squeakfoundation at lists.squeakfoundation.org>
Sent: Friday, February 21, 2003 9:45 AM
Subject: [Squeakfoundation]Re: Taking control of parts of Squeak


> 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
>
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation