Karl Ramberg karl.ramberg@chello.se wrote:
lex@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