[M3devel] HEADS UP: Release engineering, was: Re: CM3 Release
Tony Hosking
hosking at cs.purdue.edu
Tue May 5 01:13:57 CEST 2009
On 5 May 2009, at 00:46, Olaf Wagner wrote:
> 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
I have the minimalist version almost ready for checkin.
> 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, ...
I'd prefer to see stability here for now, rather than on over-the-top
performance drive -- there are better solutions out there that we can
engineer in, but getting them in may require a stabilization period.
> 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
>
More information about the M3devel
mailing list