[M3devel] HEADS UP: Release engineering, was: Re: CM3 Release

[Olaf Wagner]

Now it's May 4th, and I feel we should turn to the official release
again.

Have any of the open issues been closed? Offhand I remember

  o REFANY/TAGGED REF extensions

  o alternative TEXT implementation

  o complete switch to new Unix headers

  o working cvsup (OK AFAIK)

  o formsvbt crashes

  o performance issues: threads, exception frames, texts, ...

There are probably more. A short status from those who know would
be great.

We must also decide which platforms _must_ be part of the release.
I'd suggest AMD64_LINUX, LINUXLIBC6, FreeBSD(4/7?), SOLgnu,
I386_DARWIN (and/or AMD64_DARWIN?), and of course Windows (native and
Cygwin, however these are called these days ;-)

Should we add more? I'll need support to build several of them.

I suggest that we use the old make_bin_dist_min.sh scripts with
the core distribution. Or is something better already completely
automated (possibly by Jay)?

I'll just try to coordinate things, assign error reports, make
some tests myself and setup release candidate access when we start.
Or should we postpone one or two weeks?

Olaf


Quoting Olaf Wagner <wagner at elegosoft.com>:

> If anybody could test Rodney's TEXT changes and provide some
> information on the impacts on our applications, that would help a lot.
>
> I also wasn't able to read and understand all the mails about small objects.
> (Guessing, I'd say I'd need another day for that :-)
> Can anybody summarize?
> Has a conclusion been reached and what will be done/implemented?
> Is this relevant for the next release, or will it take longer?
>
> Olaf
>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
>
>> Rodney, sorry but I haven't tried your changes.  If your test    
>> program is available, I would be glad to compile and run it on    
>> Windows to obtain results for that platform.  Just let me know how   
>>  to obtain/install your TEXT changes and the test program.
>>
>> I am ok with Olaf's suggestion of starting the release process in May.
>>
>> Again, I will be glad to help on Windows platforms.  If necessary,   
>> I  can also test cygwin on Windows.
>>
>> If we need to test/build/release on HPUX, I have an old v10 system   
>> I  can pull out of storage (note that v10 is an older version of   
>> HPUX  and not current).
>>
>> Regards,
>> Randy Coleburn
>>
>>>>> "Rodney M. Bates" <rodney.m.bates at cox.net> 4/13/2009 5:24 PM >>>
>> Any opinions about the TEXT branch?  Anybody tried it? To summarize:
>>
>> - I have tested it extensively on LINUXLIBC6, with a large random
>>  test program and two successive rebuilds of CM3.
>>
>> - It makes no changes in data structure, neither to static declarations
>>  nor to invariants.  Thus it creates no compatibility problems with
>> existing
>>  pickles, etc.
>>
>> - It slows down concatenation, but more than makes it up in other
>>  string accessing operations, if the numbers of concatenations and
>>  accessing operations are equal.
>>
>> - It cuts down on tree depth and even more or recursion depth
>>  (which implies needed stack space.)
>>
>> - This effect is dramatic when strings are built by "linear" concatenations,
>>  i.e., strictly left-to-right, or vice versa.  Gains are moderate when
>>  concatenations are random.
>>
>> - It allocates a lot more storage, but abandons a lot more garbage,
>>  retaining somewhat more space when lots of old strings are retained
>>  along with newly-built ones.  It probably retains less when operand
>>  strings of concatenations are not kept, but I haven't measured that.
>>
>> - Strategies are partial rebalancing of concatenation trees, flattening
>>  of short concatenations, elimination of a lot of tail-recursion, and
>>  recursing on the shorter side.
>>
>>
>>
>> Olaf Wagner wrote:
>>> Well, that's a quite long list; but many things are bug fixes anyway,
>>> and wouldn't be affected by a code freeze, while others are already
>>> finished (as integrating CVSup, as I understand).
>>>
>>> The only thing we should not do is introduce new platforms while
>>> trying to get the system stable. We should concentrate on installation
>>> support and bug fixing.
>>>
>>> I'd suggest to start the release process in about two weeks at the
>>> start of May. That should give everybody enough time to either finish
>>> their ongoing work that shall make it into the release or decide to
>>> postpone it ;-)
>>>
>>> Any objections?
>>>
>>> Olaf
>>>
>>> Quoting Jay <jay.krell at cornell.edu>:
>>>
>>>>
>>>> > > o When should we start? I.e. wha changes would you like to complete
>>>> > > before we start the release process?
>>>>
>>>>
>>>>
>>>>
>>>> I'd like to see the formsvbt crash debugged and fixed, unless I'm
>>>> the only one seeing it.
>>>>
>>>> I only see it on Solaris and PPC_DARWIN but haven't tried "everything".
>>>>
>>>> I'll try to get this.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I'd also like to see:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  FreeBSD/x86 switched to the new Unix/*.i3 files. I'll do this.
>>>>
>>>>    Maybe also I386_DARWIN, AMD64_DARWIN, but I don't have the hardware.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  $ORIGIN/LD_LIBRARY_PATH resolved a bit further, probably very
>>>> little work  (I'll do this).
>>>>
>>>>  Basically just 1) put buildlocal back how it was 2) push it across
>>>> more platforms e.g. I think FreeBSD/x86 is the main one missing,
>>>> but  I'll get to it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  cvsup building and in "std"  (I'll do this, probably very little
>>>> left here really.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  -- beyond this, not required for release --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Maybe more AMD64 releases, e.g. NetBSD and Solaris. (If I get to it).
>>>>
>>>>   (could be "mingw64" is good enough to try AMD64_NT now).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Maybe update gmp/mpfr to fix the "maintainer" problem. (not likely
>>>> by me)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Maybe more new/resuscitated platforms..HPPA64_HPUX, IA64_*, *_VMS,
>>>> ALPHA_*, ARM_*, *_IRIX, *_AIX, MIPS64_*.... but these take back
>>>> seat  to important fixes in existing platforms.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Fix NT386 to use setjmp3 instead of setjmp so exceptions don't
>>>> skip C __finally blocks. I've just been very lazy here, should
>>>> demonstrate the behavior with a test case, then fix it..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Maybe fix cm3cg so other -g options besides -gstabs works, like
>>>> plain -g, -ggdb, on at least one platform -gstabs isn't supported,
>>>> leaving nothing, because others cause internal compiler errors, like
>>>> on HPPA64_HPUX.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  Oh, and NT386GNU probably switched back to Win32 threads.
>>>> Otherwise one of the test cases hangs and it doesn't look easy to
>>>> figure out. I'll do this shortly if I remember.
>>>>
>>>> But I also wouldn't mind if this platform isn't officially released
>>>> either (unless someone else wants to support it).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Debug why many NT386MINGNU gui apps crash..but also probably just
>>>> don't release this platform and ok asis.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  - Jay
>>>>
>>>
>>>
>>>
>>
>>
>>
>> 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.
>>
>>
>
>
>
> -- 
> 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



-- 
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