[Squeakfoundation]Taking control of parts of Squeak
Daniel Vainsencher
danielv at netvision.net.il
Tue Feb 25 01:06:00 CET 2003
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
More information about the Squeakfoundation
mailing list