[IMPORTANT] Concrete proposals!

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Mon May 12 15:11:33 UTC 2003


On Mon, May 12, 2003 at 10:24:33AM +0100, goran.krampe at bluefish.se wrote:
> Hi Joshua!
> 
> "Joshua 'Schwa' Gargus" <schwa at cc.gatech.edu> wrote:
> > On Thu, May 08, 2003 at 02:42:23PM +0100, goran.hultgren at bluefish.se wrote:
> [SNIP]
> > > Problem #1:
> > > The decision process is... well, do we even have one? ;-)
> > 
> > <snip>
> > 
> > Your PROPS proposal is a positive step for formalizing proposals so
> > that they don't just get forgotten in the rest of the list mail.  This
> > is good.  They don't solve anything on their own, though.  For
> > example, I have the perception that it is currently very difficult to
> > get anything into the update stream that isn't a FIX or REMOVAL.  As
> > long as they don't go against the modularization effort (eg: by adding
> > more circular dependencies between chunks of code that will eventually
> > become packages), then there is no reason (that I see) not to add
> > enhancements other than fixes/removals.
> 
> We agree on this. And yes, perhaps we have made it sound like
> enhancements simply can't go in - but that is not true. Have you read
> the plan for 3.6? Let me quote:
> 
> >...
> >2. Then when we have a reduced image we move forward with some
> >aggressive harvesting. 

"when we have a reduced image" is the operative phrase here.

> >Sure, we have performed harvesting during step 1
> >above - but not "the heavy stuff" since we wanted to concentrate on the
> >removals. The following areas should probably deserve our *primary
> >attention* beside the regular harvesting:
> >	1. Work produced by MCP.
> >	2. Work produced by KCP.
> >	3. Anthony's runtime enhancements.
> >	4. Craig's simulator fixes.
> >	5. Substantial enhancements currently on SM need to be reviewed and
> >possibly applied.
> >
> >Number 5 above refers to packages on SM that essentially are
> >improvements that could be merged into their appropriate package inside
> >the image. For example, if there are very nice improvements to Morphic
> >they could be folded in as long as they don't "produce inter-package
> >dependencies". Since it will take a long time before Morphic turns into
> >a real external package we can't keep these on hold. We will compile a
> >list of the packages that could be considered.
> >
> >Then of course we have the general harvesting going on. :-) The list
> >above is so that we do not miss these - it would be harmful to
> >especially the MCP/KCP projects if their work didn't get the chance.
> >...
> 
> Here you see that we have *explicitly* stated this. Right?
>
> > Your proposal will help us remember that, yes, so-and-so proposed
> > such-and-such, but won't help code into the image unless there is
> > a change in attitude about what gets in and what doesn't.
> 
> What do you mean with "change in attitude"? Reread the plan I quoted
> above and explain what you think is wrong.

I have had the feeling that it is not worth it to fix various small 
annoyances in the development environment UI because I didn't think
that they would be likely to be accepted into the update stream.

The 3.6 plan focuses on MCP/KCP, which might reasonably be considered
as part of the modularization effort.  Anthony's and Craig's changes
are "under the hood".  The remaining category, "substantial packages
on SqueakMap", doesn't give me much more hope that small UI
enhancements have a chance of getting into the update stream.

> 
> > > ----------
> > > Problem #2:
> > > There is a perceived lack of Vision from the Guides. The community wants
> > > to know "where" we are heading. I have picture hanging in front of me as
> > > I write this. It is a poster from ThinkGeek. It looks like this:
> > > http://www.despair.com/ignorance.html

I'll respond to this in my response to your response Andreas' response :-)

Joshua



More information about the Squeak-dev mailing list