All,

I'm still looking for someone to step up and say, I'll maintain
Cryptography.  I have a new addition to that package.  So far an email to
the author and a post here to anyone that knows anything about the package
has gone nowhere. 

So what do you suggest?  

1) Email everyone that has ever touched the package?
2) Volunteer to maintain the package myself?
3) I posted the class to Mantis( http://bugs.impara.de/view.php?id=2086 ),
should I just assume that that is good enough?  
4) Forget it and keep the changes to myself?

The last part #4 is something to be considered.  In some cases there will be
good work done but not shared if the process breaks down or there is no
process.

Ron

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Lothar
Schenk
Sent: Wednesday, October 19, 2005 9:40 AM
To: The general-purpose Squeak developers list
Subject: Re: Need to do something

Am Mittwoch, 19. Oktober 2005 00:11 schrieb Andreas Raab:

> stéphane ducasse wrote:
> > Yes please propose something that we can start building on top.
>
> And I thought that was just what I did ;-) So again:
> - More maintainers. Actively look for people with a vested interest in
> the various areas and let them deal with whatever comes up. Trust them.
> Give them responsibility, let them decide which direction to take.
>
> - Change the role of what is currently understood to be the "harvesters"
> to something like a "release tester" group. The role of which group is
> mostly to do integration testing by loading the packages from the
> various maintainer's sites and test them. If there are issues the
> release testers should report them back to the package maintainers and
> work with them to fix these. Unilateral actions should only be taken if
> a maintainer is unresponsible and there is real time pressure.
>
> - Another task of the release maintainer could be (if that is deemed
> useful) to figure out how to load the various package versions to update
> an existing system. Or maybe that's the task for an entirely new group
> of people.
>
> Obviously, the main issue is #1.

May I make a few additional suggestions (for what they're worth, they are 
free ;-) ).

When I speak of a maintainer in the following, this can be understood to
refer 
also to a maintenance team, of course. Also I'm talking of the official 
release(s) here, not private images.

(1) Assign maintenance responsibility on a per class basis. That is, every 
class in the system should have an appointed maintainer.

This does not mean, that one can't assign maintainers by packages. But in
that 
case, make sure every class in the system belongs to one and only one
package 
from the maintenance point of view; and then the package maintainer simply 
becomes the maintainer of each class in the package.

(2) Make sure, every change of a particular class has to be approved by the 
assigned maintainer. If he doesn't approve, the change is discarded.

This emphasizes the aspects of code ownership (both in the sense of 
responsibility and trust by the community) that you have brought up.

I'm sure this policy would be enforceable by a proper tool support.

(3) Last, and most important: If a class (or package) doesn't have an
assigned 
maintainer, it doesn't get maintained! No changes whatever, even the 
slightest one. This means no enhancements, no bug fixes, nothing whatever. 
The class or package stays as it is.

Some may raise the point that this will hinder progress of the system as a 
whole. Actually, that's the intention here. It is the only guaranteed to
work 
way of ensuring that a package or class that needs a maintainer actually
gets 
one - by ensuring that it hurts if it doesn't get one. (It's a time-proven 
sure-fire way in a commercial enterprise for a manager to either get more 
personnel -- or get his unit dismantled *grin*).

So, if the owner of package "Morphic" (just as an example) thinks he needs a

change to one of the Collection classes, which let's say are in package 
"Basic", and if package "Basic" has no maintainer, there's no chance of that

change to the Collection class being accepted. Believe me, if this is a 
really important change (to someone), then package "Basic" will have a 
maintainer in no time.

Lothar