Squeak 3.8 status

lex at cc.gatech.edu lex at cc.gatech.edu
Mon Aug 2 15:11:46 UTC 2004


Karl Ramberg <karl.ramberg at chello.se> wrote:
> lex at cc.gatech.edu wrote:
> > My favorite direction to go in would be to put reasonable people in
> > charge of various parts of Squeak, as we have already begun to do so.
> > And if some part of Squeak is too obscure for anyone to volunteer as the
> > maintainer of it, we shouldn't lose too much sleep that it is not being
> > maintained.  Once maintainers are in place, we can trust those guys to
> > do the right thing most of the time and not subject them to lots of
> > cross examination on every little change.
> 
> Do you mean having different people issuing updates for diffrent parts
> of Squeak in the update stream ? Or splitting the image up and maintain 
> packages seperatly onSqueak Source and then pull them together 
> using Squeak Map. 
> I can understand that Doug have a heavy responability and workload 
> and maybe his role could be maintained by a group of people.


No, I mainly mean that there should be people who can say "yes" to the
really obvious bugfixes without needing two approvals and an SUnit test.
 These people are also likely to know who to communicate with in the
non-obvious cases.

The portions do not have to be removed from the image.  For example, we
could really use an EToys czar, I believe, even though EToys is too
intertwined with Morphic to extract on its own.

> > If there is a problem with getting people to volunteer, then perhaps the
> > first person to post a fix to a new area should get a chance to become
> > the maintainer for that part.  After all, they new enough to fix
> > something, so they have to be a reasonable choice.
> 
> Or this will scare people away from fixing because they get the 
> responsability for some buggy old stuff ;-)
> But I guess since they fixed it they want to use it...

They can refuse if they want.  And also, they can perfectly well
delegate their authority.  If they aren't sure they don't *have* to say
yes on something.

Also, if anyone else steps up later, they can always offer to pass on
the maintainership.


> > Anyway, to make this approach work really well, BFAV would need to have
> > tags for which part of the system a bug report is associated with, and
> > it should be possible for people to reassign those tags.  Alternatively,
> > of course, we could use any existing off-the-shelf bug tracker; all of
> > the ones I've seen have this functionality.  Even email might work
> > better, honestly, if we also had a swiki page listing the points of
> > contact for each portion of the system.
> 
> There is always room for improvments. But some decitions have to be made.
> Should we split the image into packages? When is this going to happen ?
> How is packages maintained? Who maintain them ?


Should we split?  Yes when easy, no when hard.

When?  How about now?

How are they maintained?  It depends on whether the package was actually
removed.  If the package is on SqueakMap, then maintain it there.  If
the pseudo-package is in the image, then use the update stream.


Who maintains them?  The assigned maintainer.  :)  Actually, the
assigned maintainer can do as little as arbitrate incoming suggestions
and patches.  They don't have to do any actual work themselves, but they
*must* deal with the influx of patches somehow.


One way to look at my suggestion is that I am wanting us to route
communication towards the people who can actually do something
meaningful.  There is a wealth of discussion we can have on the details,
but the first steps are that we have the technology for the routing, and
that we have at least *one* person serving as the point of contact for
each package.

Once we have that in place, we can discuss things like:

	- Maybe the kernel should continue to be committee-maintained
	
	- We need away to do non-maintainer-updates, if the official
maintainers disappears from the planet for a while
	
	- We eventually will want a way to forcibly oust a maintainer who has
disappeared.  It's an ugly scenario but it will happen and we might want
to be prepared.
	
	- What do we do with packages no one feels real qualified about?  What
is our process for easing unmaintained parts of Squeak out of the main
image?


But these are minor details compared to the main one.  Let's not just
divide, but divide and specialize.

	
-Lex



More information about the Squeak-dev mailing list