[V3dot10] V3dot10 process and meta-problems

[Ralph Johnson]

On 5/17/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>I think that the majority of the problems that previous teams had can be
> resolved by improving the tools.

We need better tools.  I agree completely.  Better tools will not make
all problems go away, though.  In fact, I do not think they will make
the biggest problems go away.  I think the biggest problem is that the
quality of code in Squeak is not nearly high enough.  It is too buggy,
the code is too ugly, and it is a big ball of mud.

The process you describe works in an XP project, where everybody who
is committing is in the same room, or at least is in constant
communication with everybody else.  It won't work is a highly
distributed project.  Open source projects always have a small set of
"committers", and that is basically what the release team is.

>  My suggestions would be to plan a number of items and see them all worked
> on together. Integrating all of the tasks simultaneously and regularly. This
> is effectively what I have done on 3.9.1

It is easy for one person to integrate.  It is hard for an open source
group to plan.

I don't think your diagrams are accurate.  Edgar is just taking
changes that other people have made and putting them in a single
image, converting them into MC format.  This is hard enough.  He
doesn't fix bugs, refactor code, etc.  Well, sometimes he does, but
that is not what he is doing as an officlal member of the release
team.  We keep the list of proposed changes public.  Anybody can file
them into their image to try them out in advance of an official
release.

>  This was not viable before, because such a build script would constantly
> run into problems. For example, rather than tweak the TTFFont Speedup fix to
> make it loadable, I spent a couple of days fixing the loader so the problem
> should not reoccur. Removing loading order dependencies should also make
> this simultaneous-integration approach one step closer to reality.

I think that change to TTFFont broke something.  I get font errors
nearly every time I try to test a package.  I'm hoping that once I
figure out the problem, it will be easy to fix.  But we might need to
back out that change, or some other change to fonts.  This is why
integration is difficult.  The tools are only part of the problem.

>  I demonstrated this 4 months ago, and Installer supports the ability to
> have stable/unstable/personal versions of each script, via its search 'path'
> parameter.

i tried it out and it didn't work for me.  Does it work now?  How can I tell?

Keith, be very conservaitve about the changes you make to MC.  You
will find that getting people to use your version is nontrivial, and
the more changes you make, the harder it will be to get people to use
it.  There are already too many versions of MC.  Integrating those
changes is valuable, making a new version that is incompatible with
all the others is not valuable.

-Ralph