[M3devel] organization of scripts folder

[hendrik at topoi.pooq.com]

On Thu, Oct 29, 2009 at 10:14:51AM +0100, Olaf Wagner wrote:
> Hi Randy,
> 
> I think it is a good idea to clean up and restructure the scripts
> folder. The current layout has grown and was never 'designed'.

Speaking as a naive Modula 3 user and installer (well, not so naive
after all these years), I found the scripts confusing.  The biggest 
problem was to distinguish scripts that were meant to be used directly 
by the user and those meant to be used by other scripts.  I also found 
that the scripts were not adequately documented -- oh, they were 
documented enough that once you were familiar with them, you'd know 
where to look for detaile you had forgotten, but not so a beginner would 
find it easy to figure which to use in the first place.

Any documentation of reorganisation that makes these distinctions clear 
would be welcome.

> 
> However, we should make sure that nothing breaks when we move scripts
> around, especially for regression testing in Tinderbox and Hudson.

Well, if reorganising makes it easier to get our current release through 
regression testing, I'm all for it.  But I'd say it's really important 
to get a release out -- at the moment we don't really have one that's 
adequate for someone newly sold on the merits of Modula 3.  So if 
there's a signoficant risk of a reorganisatin delaying things, perhaps 
we should hold off a bit.

It seems that the current RC3 is not really adequate -- important 
components like m3gdb don't install properly from the binary downloads 
directory.  And RC4 is held up on regression testing which shows 
significant problems in a few packages (Juno ocmes to ming).  These 
problems appear to involve the interaction between the package, garbage 
colletion, multitasking, and the details of particular platforms.  They 
are difficult problems, and it is not at all clear that they can be 
solved quickly, or even whether they are regressions.

I'd very much like to see a RC4 that fixes the problems we've already 
fixed in RC3.  Some of them seem to be installation issues.  At 
least, with a current RC4, flaws and all, we would know for sure 
whether the installation problems in RC3 have really been fixed.

> So changing things is fine as long as we consider and correct the
> potential damage. As a backup, we could provide a script which creates
> symbolic links for some current scripts which are called from outside
> the scripts package itself in our test frameworks.

That could help.

-- hendrik
> 
> Olaf
>