[Squeakfoundation]Taking control of parts of Squeak

[Daniel Vainsencher]

Like many things in life, it's not complicated, but it's subtle...

Berners, I think everyone is curious about you intentions. If you could
put out a draft of a "release plan", that'd be good.

What do you want to achieve (in detail), what classes/protocols are you
targeting, what you want from the community/possible collaborators
(Anthony's compiler work comes to mind).

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.
> 
> Cheers,
>   - 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
> > 
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation