RE: Taking control of parts of Squeak

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 <[email protected]> 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: [email protected] 
> > [mailto:[email protected]] 
> > On Behalf Of [email protected]
> > 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" <[email protected]> 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
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> > 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Thu Feb 27 19:46:43 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 32556 invoked from network); 27 Feb 2003 19:46:43 -0000
Received: from mailout.whidbey.net (209.166.64.124)
  by mail.theinternetone.net with SMTP; 27 Feb 2003 19:46:43 -0000
Received: from vdsl-72-234.whidbey.net ([209.166.72.234] helo=ned)
	by mail1.whidbey.net with esmtp (Exim 4.12)	id 18oTxw-0004ga-00
	for [email protected];
	Thu, 27 Feb 2003 11:45:12 -0800
From: Ned Konz <[email protected]>
To: [email protected]
Date: Thu, 27 Feb 2003 11:45:59 -0800
User-Agent: KMail/1.5
X-Image-URL: http://bike-nomad.com/nedicon.jpg 
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[email protected]>
Subject: [Squeakfoundation]Outstanding 3.4 bugs?
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2003 19:46:44 -0000

These bugs (and more, like the much-discussed bug with adding an 
instVar to ClassDescription) still exist in 3.4g. Are we going to do 
anything about them?

[BUG] Flap icons in tools flap disappear in 3.4 (23 February 2003) 
Jim Benson (23 February 2003) 
http://swiki.gsug.org:8080/sqbugs/715.html

[BUG] Setting a gradient background after setting a texture background 
(21 February 2003) 
Michael Roberts (21 February 2003) 
http://swiki.gsug.org:8080/sqbugs/711.html

[BUG] TextPropertiesMorph - overflow (28 January 2003) 
Webb McDonald (28 January 2003) 
http://swiki.gsug.org:8080/sqbugs/691.html

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE