[M3devel] package groups question

[Randy Coleburn]

Olaf:
 
Thanks for the brief history lesson.  These definitions coincide with my recollection.
 
>From what I've gleaned in the discussions and the current documentation, I think most everyone has settled on the idea of having 2 "binary" distributions for this release:  "min" and "std".
 
My problem has been a misunderstanding of "min", having thought that I could use min to bootstrap the compiler.  My bad here.
 
Jay has been talking about tracing graphs and figuring out everything from m3makefiles.  In a distributed development environment, I'm not sure this approach works well.  I am fine with continued use of PkgInfo.txt.  I've been able to generate scripts using it with relative ease.
 
For this release, I think we have at least 2 groups of "users" to be supported:
1.  The power users who know enough to tweak the details of their installation, rebuild the compiler, etc. etc.  They want the flexibility to tailor everything.  You, Jay, Tony, etc. are in this camp.
2.  The average or even new user who just wants a simple install that works out-of-the-box.  He doesn't want anything complicated to install.  He probably won't rebuild the compiler and is content to update his system whenever a new release is made.  Obviously, folks from camp #2 may promote themselves to camp #1 after sufficient experience.
 
If we agree on these two camps, I think that your definition of "min" is ok, but I would argue that "std" should include the documentation, examples, and pre-built binaries and sources for all packages known to work on all platforms.  That would allow "std" to satisfy camp #2.  Thus, "std" should be the recommended option for most users.  The power users in camp #1 can start with either "min" or "std" and they have the knowledge to transform either of these into "all" or whatever sub-grouping they want.
 
I appreciate everything Jay is doing, but I think he is so deep in the details right now, and also still looking forward past this release, that his responses to my questions aren't really answering what I'm trying to discuss regarding nailing down this release.  Sure, with complete knowledge you can do most anything, but I'm looking at what I can do using cm3ide and the cm3.exe builder/compiler and the "min" and "std" releases using the default install locations.
 
I'm heading south for a family reunion.  I'll try to check email some this weekend, but it will be sparse.
 
As soon as I can, I'll try to put some of what I've gleaned in a text file we can add to the documentation/web.
 
Regards,
Randy Coileburn

>>> Olaf Wagner <wagner at elegosoft.com> 07/31/09 10:08 AM >>> 
Quoting Tony Hosking <hosking at cs.purdue.edu>: 

> I don't care if future versions are not compilable with old cm3. But, 
> vice versa, old versions should always be compilable with new cm3. 
> 
> My gut feelings run along the lines of what Randy has said. I do 
> think that the average user should accept std as the install, while 
> min is for power-users who know what they are doing. Does that jive 
> with other people's expectations? 

Sorry, I only now caught up with _some_ of the mails on the m3devel 
list. Too much traffic for me to digest. 

I gather there's been a long discussion that `min' is not really 
useful as it is not enough to build the system. When we started 
the cm3 5 business many years ago with lots of uncompilable sources 
from Farshad Nayeri, we invented the following sets of packages: 

all - obvious meaning. most packages did not compile at all. 
std - the set of packages shipped as compilable and usable with 
every new release 
core - a useful but small set of packages including everything to 
bootstrap the compiler 
boot - the minimal set to bootstrap the compiler 
min - the minimal set useful for anyone (not wanting to compiler cm3) 

As of today, std = all, and boot isn't used any more as far as a I see. 

I'm fine with any changes in the pragmatics or intended use of these 
package sets though. Just wanted to throw in some history. 

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

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090731/07fb8779/attachment-0002.html>