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

[Rodney M. Bates]

Randy Coleburn wrote:
> 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.
It's in a branch named:

devel_m3core_text_newtext_branch

It's all part of m3core, which you have to rebuild and ship.  

The test program source code is in m3-libs/m3core/tests/newtext/src of 
the branch, along with
a README file.
>  
> 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
> >>
> >
> >
> >
>
>