[Squeakfoundation]Taking control of parts of Squeak

Andreas Raab andreas.raab at gmx.de
Mon Feb 24 22:10:36 CET 2003

Hi Göran,

> 1. A very small rule set for being a kernel package maintainer. Say,
> about 5 rules? :-)

I dunno. It seems very hard (at least to me) to come up with a set of rules
here. Something more loosely defined such as "guide lines" might be more
appropriate (this is why I was referring to a "general outline"). 

But let's see. One rule (or rather guide line) which I think is important
for the community is a "controlled rate of evolution". What I mean by this
is that while we expect the kernel packages to evolve as any other part of
Squeak there is always the danger of breaking existing stuff (much more so
than in any other package). I _think_ that this means that larger scale
changes have to be discussed with the community first and that a time line
for deployment needs to be developed prior to making it part of the "core
release". It should give other maintainers enough time to get the changes
integrated and should probably come along with some "migration support"
(whatever this means in the concrete case - it could be automated tools, it
could just be an FAQ).

Hm ... just thinking about it I think that's essentially the only "rule" I
can come up with. Other than that there seems to be no difference between a
package which is part of "kernel Squeak" and one that isn't. It's really the
aspect of evolution (e.g., rate of change, stability etc) that makes a
kernel package "different" from any other, which effectively means that a
kernel package maintainer needs to be a bit more conservative for her stuff
than Joe-Doe.

  - Andreas

> -----Original Message-----
> From: squeakfoundation-bounces at lists.squeakfoundation.org 
> [mailto:squeakfoundation-bounces at lists.squeakfoundation.org] 
> On Behalf Of goran.hultgren at bluefish.se
> Sent: Monday, February 24, 2003 9:28 PM
> To: Discussing the Squeak Foundation
> Subject: RE: [Squeakfoundation]Taking control of parts of Squeak
> Hi all!
> "Andreas Raab" <andreas.raab at gmx.de> wrote:
> > Colin,
> > 
> > > However, I don't know that we need to have a big rules 
> discussion. 
> > 
> > True. But I think some general outline of what is expected 
> from someone who
> > wants to "take over" a portion of kernel Squeak is good. It 
> simply means
> > that there's a common understanding within the community of 
> what is expected
> > from a "kernel package maintainer". This can only help as 
> we are moving
> > towards a more decentralized model of development.
> I agree.
> I also agree with Colin that we shouldn't get tangled in trying to
> establish a complicated rule set that noone will follow and just make
> people hesitant of becoming a kernel package maintainer. :-) 
> But I think
> we can avoid that.
> But again - for a *particular* maintainer to present how he/she/they
> intend to maintain a *particular* package is very good.
> So, to be a bit constructive here - I would like the community to
> produce the following:
> 1. A very small rule set for being a kernel package maintainer. Say,
> about 5 rules? :-)
> 2. Some form of simple process how to become a kernel package
> maintainer, how to stay one :-), and how to move the stick to someone
> else.
> And lets stay out of the "technical how" for a bit. We can attack that
> as the next step. So... is this admittedly short list what we need? If
> it is then I can continue by presenting a little draft based both on
> ideas from Roel etc.
> regards, Göran
> PS. I intend to produce some form of proposal here on this list and
> then, when we agree on it - post it on squeak-dev and see what all
> others think.
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation

More information about the Squeakfoundation mailing list