[M3devel] Release notes comments

[Olaf Wagner]

Quoting Randy Coleburn <rcoleburn at scires.com>:

> 1.  The section on "Package", particularly the first paragraph, I   
> think is a bit confusing.  The CM3IDE documentation includes a lot   
> of information on packages, so perhaps the missing link in this   
> section should reference that documentation.  To me, a package is a   
> set of sources that together represent one compilation unit for the   
> purpose of building a library, program, or other assemblage of   
> information (e.g., documentation).  Each package resides in a   
> directory (folder), with sources and generated files in   
> subdirectories (sub folders) of the package's folder.  In the   
> top-level CM3 source tree, packages are grouped into categories,   
> with each category represented by a subfolder rooted in that   
> top-level, and the packages comprising each category rooted in the   
> category's folder.

Actually that part was copied from an older document by Neels, I
think. What's the exact link you have i nmnd?
http://www.opencm3.net/doc/help/cm3/packages.html?

> 2.  I presume that we do intend to make NT386 available for this   
> release, even though it says "Not Available Yet".

Yes. Nobody has built any though. You or Jay may want to do that
once we have fixed RC2.

> 3.  I find the "-bin-min-" and "-bin-core-" terminology a bit   
> confusing.  To me, the "core" of something is the "heart" or   
> "minimal" part of it.  Would it make more sense to rename   
> "-bin-core-" to "-bin-std-"?  Indeed the explanation given for   
> "core" says in one place that it represents a "standard"   
> installation.  In another place it is called "package pool".  Also,   
> "min" in one place is called the "central installation hierarchy".    
> Suggest we be consistent.  To me it makes more sense to have "min"   
> represent the "minimal installation" and "std" the "standard   
> installation" and "all" represents "everything."

I grant it may be confusing, but am somewhat reluctant to change that
now. It's legacy from the older package collections (all defined
in pkginfo.txt) and used by a lot of scripts, IIRC. We have a
`standard' collection there, too, but that has grown to `all' in the
meantime. `min' was always the smallest possible installation
(just cm3, m3core, libm3). `core' could be thought of as the
packages needed to build the system itself (plus some useful
libraries :-/). You're right, it's not really accurate, but I'd
rather not change it for this release. Anybody's welcome to do
it afterwards. Perhaps we could improve the explanation on the
web pages?

> 4.  I don't understand the "-bin-ws-" concept of "precompiled user   
> workspace" and how it would be useful.  Please elaborate.

Copied from a mail I sent to Jay some weeks ago:
  ----
The idea was to reduce the number of packages, as M3 does not
really support the separation of source and derived files for binary
packages. So why not just enrich the source with just the products
needed for shipping? This is sort of the smallest supported _M3_-binary
package.

Both system-dependent source and binary packages can be based on the
same collection of ws packages.

Traditionally CM3 offered only sources packages except for the minimal
installation archive. There were lots of problems with

  o people understanding how to compile the source and
  o actual compilation errors due to miscellaneous causes

People wanted something that is easy to install (without using lots
of complex scripts). So I extended the standard cm3 builder so it can
be used for such an installation.

These are exactly the ws archives. M3 source and derived files which
are needed for shipping an M3 package, but not more. I found that
rather nice.
  ----

Does that make it clearer?

> 5.  All of the instructions seem to apply for UNIX-like   
> environments.  We need to augment these to include how to do it on   
> non-Unix environments, such as Windows.  For the scripts, like   
> "install.sh", do we intend to provide Windows command/batch files,   
> e.g. "install.cmd" or "install.bat"?

Yes, I haven't spent much thought on Windows until now. I hoped that
you or Jay will do that. Of course I've also overseen the install.cmd
scripts for Windows :-/ Should we use cmd or bat? Could somebody
quickly provide the equivalent of this loop, so that I can
automate it?

  ----
#!/bin/sh
HERE=`pwd`
for p in  m3-win/import-libs ... m3-comm/tcp; do
cd $p
cm3 -ship ${SHIPARGS}
cd $HERE
done
  ----

> 6.  When we finally settle on a release name, need to update the   
> names in these instructions, e.g., replace "d5.8.1-RC1" under   
> "Installation Procedure", and "RC1" in other places.

Much of the RCs is generated, but we'll probably have to replace some
manually.

> 7.  "Installation Procedure" step #5, change "shop" to "ship".
done

> 8.  "In case of problems" step #4, last line, change "volunteers" to  
>  "volunteer" and change "his" to "his/her".
done

> Hope some of this helps.

Sure. Updates are online and checked-in.

Thanks for the comments,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194