[IMPORTANT] Concrete proposals!
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Mon May 12 09:10:14 UTC 2003
"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Göran,
> Here are a couple of comments:
> > -------
> > Problem #1:
> > The decision process is... well, do we even have one? ;-)
> > The protocol is for dealing with proposals. Python has a scheme called
> > PEPs - http://www.python.org/peps/. (Python Enhancement Proposal). I
> > would like to simply call ours "PROPs" - as in proposals.
> > Exactly how this Guide deals with this process is up to that person to
> > figure out. That is called delegation. I would assume though that the
> > Guide doing this looks hard at Python for inspiration.
> I see two problems with the above. The first (and most important one) is
> that it's unclear what the intended result of a [PROP] is. Let's say I'm
> writing a [PROP] for including package XYZ. I write it up and the guide in
> question says, "fine, let's do it". Then, what would happen? Considering
> that much of the talk is about reducing image size etc. it seems unlikely
> that this is just going to be pushed into an update stream, right?
I am not sure what you mean. The Guide wouldn't just decide the issue -
but he/she would make sure the ball is kept rolling and discussed and
eventually also is responsible for boiling down a decision from it all.
And we are talking about a *general decision process* for the community
regardless of issue at hand - I can't see what "reducing the image" has
to do with this.
But anyway - "including package XYZ." can mean different things. Since
you are mentioning the update stream it sounds like you meant "stuff it
into the minimal/basic/full image". And since we are partitioning the
image into packages this really feels like a step in the opposite
But if you instead meant "make package XYZ be a part of the official
Squeak" it would mean that package XYZ, depending on its nature, would
be a part of minimal/basic/full *as a package*.
And secondly, if XYZ is an enhancement to code currently in the image
(and said code will of course eventually be turned into a package) then
we can lift it into the updatestream as long as it doesn't go against
the partitioning effort. This means that as longs as the enhancement
doesn't increase the spaghettiness of the image it can surely go in -
especially if the enhancement otherwise suffers from a great chance of
code rot waiting outside of the image.
END BIG SIDENOTE
> A second problem I see is the lack of documentation in the above. I liked
> very much the pointer to Zope's Fishbowl process sent by Stef. There's
I will read it.
> always a good chance that there are objections and it needs to be clear what
> the problems were and how to address them. For example, consider a case in
> which you have some package where someone (maybe from KCP) looks at it and
> says "that's really bad engineering - there's about a gigazillion
> #isKindOf:s in there not a single test etc. these guys ought to fix X, Y,
> and Z before this gets in". Let's say that this goes back to the author and
> the author says, okay, he's going to fix it. Then he's running out of time
> and things get forgotten. Some time later, some jerk (like me ;) is angrily
> requesting to know why this never made it.
> It feels to me that good documentation in this process is absolutely
> essential. It allows people to see what's happening without having to follow
> each individual discussion on Squeak-Dev, it allows people to chime in if
> help is needed (in the above for example, someone else could address the
> problems if the author agrees) etc.
I definitely agree and the idea was that the Guide responsible for the
PROPs will also be responsible for making sure that arguments, critique
and subsequent decisions are well documented together with the PROPs. So
a full trace of the PROPs and why they ended up where they ended up is
of utter importance.
So no disagreement here - I just didn't want to go into that detail at
> - Andreas
More information about the Squeak-dev