[Packages] Split-Join in development universe etc

Jason Johnson jason.johnson.081 at gmail.com
Thu Aug 9 17:18:19 UTC 2007


On 8/9/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:

> I think it could do if you are ripping things out, since it might become
> an option for replacing those ripped out things.
> I would also like to argue for the inclusion of #askFor: as another aid
> for interacting with items that are optionally present.



And here is what makes me nervous (and maybe others as well):  I have read
the "Smalltalk Best Practice Patterns" and I try to draw a lot from the code
in the image that I feel is elegant and Smalltalk style.  And I have not
felt this pain of not having a Null object.  Maybe I haven't worked with
enough different domains yet, or maybe this is something that just doesn't
come up that much when coding in Smalltalk style.

So if we put this in then maybe someone not fully mentally integrated into
the "Smalltalk way" walks in, starts ripping things out all over the place
and before you know it we have Objective-C with a little mouse at the top.

I don't see a problem with there being a NullObject package out there for
people who do need it, or just want to use it in their code.  But why does
this need to be in the main image?  You are talking about ripping things out
of the core and replacing it with this, but keep in mind some of the people
who have worked on this code.  They apparently didn't see the need so we
shouldn't be so quick to just assume they didn't know what they were doing.
That's not to say that what they did can never be replaced, but it just
takes more thought IMO then simply making a new package out there that
people can "opt in".


Just a little dig at the process that has continued to demonstrate that
> democracy doesn't seem to work in terms of pushing innovations, but
> appears to favour the status quo



Begging your pardon, but isn't pronouncing something you happen to like as
an "innovation" a bit presumptuous? :)

Innovations have and do happen in Squeak.  But to get people on your side
you have to prove it's worth the risk.  Make an image with your Null object
and replace the things you think should be replaced and then come back and
show how it runs faster/is less code/is easier to maintain/whatever and
maybe people will start getting on board.


As a suggestion for 3.11+ my proposal is to provide the tool for users
> to specify, packages, fixes/changesets, removals. With such a tool, we
> ask community members to lay out their own road maps of items they would
> like to see in the release. For example: kernel-events-logging-solution,
> kernel-streams-replaced-with-nile, nile-streams-backward-compatibility,
> openGL-rendering, exupery -support, morphic3, system-editor,
> atomic-monticello etc etc.
>
> This encourages forks of 3.10 as each person can design their own idea
> of 3.11p (p for personal) and in their working environment develop the
> pieces that they wish to contribute.
>
> Ralph and Edgar really didn't like this multiple-forks idea, however the
> point I think that was missed is, that if all the forks and pieces of
> fork are defined in the same build tool, then they can be designed with
> integration in mind. The aim of forking is not to go off to develop your
> own squeak, but to be able to manage your branch of innovation in such a
> way as to be able to contribute it back into the main stream in the mid
> to long term, and to have it potentially visible, and potentially
> programmed into the release schedule (via the unstable branch) so that
> others in their personal-unstable-build-based-branches can integrate
> their pieces with yours.
>
> I tried using a wiki for this tool in order to promote collaborative
> working, but people did not seem to take to the idea. So instead I
> propose using a monticello package(s) to specify the parts/dependencies
> and the build processes. Doing it this way gives us the versioning, and
> merging tools of monticello to collaboratively design the release build
> processes.
>
> Then we collate a 3.11a, from the contributed roadmap ideas, into a
> stable and an unstable build process, and individually we can work on
> the pieces, until each piece is in a state that is ready to move from
> the unstable build into the stable build. Pieces that are not yet ready
> at the end of a given release-time-box, can simply be passed into the
> next release unstable build process. When the relase-time-box is
> completed for a release 3.11a-stable gets nominated as 3.11b, and only
> bug fixes are accepted. Meanwhile 3.12a begins adopting the unused
> pieces from the 3.11a-unstable branch into a revised roadmap definition.
>
> Thus bug-fix integration becomes just one piece of the process, rather
> than consuming the whole effort as it seems to now. This piece can be
> delegated to part of the team, while there are other proactive projects
> are in progress.
>
> just a few of my thoughts, and at the moment I have no time to work on
> this for at least a month.
>
> best regards
>
> Keith



I'm a little bit confused by all this.  Why does it need to be 3.11 images?
What is wrong with Damien's approach of "value add" prepackaged images?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070809/57aba01b/attachment.htm


More information about the Squeak-dev mailing list