gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] 2.6.1


From: Camm Maguire
Subject: Re: [Gcl-devel] 2.6.1
Date: 09 Sep 2003 15:05:27 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

OK Vadim, its in.  Thanks!

"Vadim V. Zhytnikov" <address@hidden> writes:

> Hi!
> 
> I just want to remind about small
> PRPCESSOR_FLAG patch (in attachment).
> 
> Camm Maguire writes:
> > Greetings!
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> >
> >>Camm Maguire ?????:
> >>
> >>>Hi again Vadim!  One other clarification---
> >>>"Vadim V. Zhytnikov" <address@hidden> writes:
> >>>
> >>>
> >>>>Camm Maguire writes:
> >>>>
> >>>>
> >>>>>Greetings, all!  You may have noticed the recent CVS activity.  Just a
> >>>>>quick summary here:
> >>>>>1) ftp.gnu.org is *still* down, so I'm proceeding with a Debian
> >>>>>  package release to see where we are.
> >>>>>2) Stable is now numbered 2.6.x, and unstable 2.7.x.  The debian
> >>>>
> >>>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>
> >>>>
> >>>>>  package can build simultaneously installable gclcvs and gcl
> >>>>>  packages to help with our development once this gets settled.  3)
> >>>>>axiom builds with 2.6.1 installed separately.  I have a prototype
> >>>>>  Debian package to release to unstable for testing shortly.
> >>>>>4) Sizes increased, but a bit more work needs to be done here I
> >>>>>think.
> >>>>>5) quite a few other changes, check the debian/changelog.
> >>>>>take care,
> >>>>>=============================================================================
> >>>>>gcl (2.6.1-1) unstable; urgency=low
> >>>>
> >>>>       ^^^^^^^^^^^^^^^^^
> >>>>
> >>>
> >>>This 'unstable' refers to the Debian unstable distribution.  All gcl
> >>>releases uploaded to Debian must first pass through unstable and
> >>>testing before they enter the 'stable' Debian dirstribution, which
> >>>should be released sometime in Dec.
> >>>Our 'unstable' means a CVS snapshot which we do not intend to install
> >>>as a tarball on ftp.gnu.org.
> >>>In any case, I'm open to suggestions on all such matters.
> >>>Take care,
> >>>
> >>
> >>I totally agree with new numbering scheme.  But I venture
> >>to suggest a bit different strategy concerning the release
> >>time (moment) and exact meaning of even and odd branches.
> >>Now we work on still not yet finally released 2.6.1 - so let it be
> >>(BTW, why not 2.6.0, am I missing something?).
> > I released a 2.6.0 snapshot to the Debian experimental distribution
> > some time ago, so we have to start from 2.6.1.
> >
> >>But, IMHO our numbering scheme should look as follows:
> >>
> >>1). We work on 2.5.X as unstable development branch.
> >>
> >>2). At some moment we decide that 2.5.854 is ready to
> >>be released as stable version and we rename it as 2.6.0.
> >>New tags 2_6_0 and 2_7_0 are created in CVS (actually
> >>2_7_0 may be forked earlier).
> >>
> > This is great except for the fact that 2.5.1, 2.5.2 and 2.5.3 were
> > stable releases.  I think it would be confusing to go back and call a
> > 2.5.x 'unstable'.  What we've essentially done is rename 2.5.4 to
> > 2.6.1, and CVS HEAD 2.6.0 to 2.7.0.  We had already forked a CVS
> > unstable off of 2.5.x long before we thought about this numbering
> > scheme, I think.
> >
> >>3). And here is my main point. We proceed to work on 2.7.x
> >>We _do_ _not_ _work_ actively on 2.6.0.  Subsequent 2.6.X X>0
> >>releases are for serious bugfixes only and maybe for some
> >>backports from 2.7.X development branch.
> >>
> > I agree with this completely, and also agree that we're currently
> > modifying 2.6.1 too much.  I hope this will be very short lived.  The
> > problem is that a number of major bug fix category changes have piled
> > up and taken precedence.  I think we're just about at the end of this
> > though.  This is somewhat akin to the linux kernel process.  Once a
> > stable '.0' release is made, most of the work still goes into chasing
> > down bugs newly discovered on release.  Unstable is forked earlier,
> > and moves very slowly until the stable becomes really stable.  Then
> > after a few minor point revisions, work proceeds primarily on unstable
> > and the stable series is only rarely touched if at all.
> > The other problem we've been having is that we've been getting a lot
> > of debugging/testing help via the autobuilders.  We need a way to
> > release frequent binary CVS snapshot builds, as we've been doing in
> > the cvs subdir of the ftp site, without interfering with our stable
> > binary builds.  I think we've finally got this.  I've reworked the
> > Debian package so that unstable and stable builds can exist on the
> > same system simultaneously.  We'll have two sets of packages, 'gcl'
> > (stable) and 'gclcvs' (unstable).  We'll mirror frequent binaries of
> > the latter under the cvs subdir of the website as before, and create a
> > separate mirror for the stable builds under a subdir called stable.
> > This way, maxima, acl2 and axiom can Build-Depend on gcl, and we can
> > release gclcvs as frequently as we'd like for testing purposes without
> > breaking the builds of these apps.
> > Comments/suggestions always welcome.
> > Take care,
> >
> >>How about this?
> >>
> >>Best wishes,
> >>
> >>Vadim
> >>
> >>
> >> -- 
> >>      Vadim V. Zhytnikov
> >>
> >>       <address@hidden>
> >>      <address@hidden>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Gcl-devel mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/gcl-devel
> >>
> >>
> >>
> >
> 
> 
> -- 
>       Vadim V. Zhytnikov
> 
>        <address@hidden>
>       <address@hidden>
> diff -uNr gcl-orig/configure.in gcl-arch/configure.in
> --- gcl-orig/configure.in     2003-03-02 18:23:17 +0300
> +++ gcl-arch/configure.in     2003-08-26 09:48:34 +0400
> @@ -57,7 +57,7 @@
>  ## host=CPU-COMPANY-SYSTEM
>  AC_MSG_RESULT(host=$host)
>  
> -PROCESSOR_FLAGS=""
> +PROCESSOR_FLAGS=${PROCESSOR_FLAGS:-""}
>  
>  use=unknown
>  case $canonical in
> @@ -1403,9 +1403,9 @@
>  
>  LIBS="$LIBS $TLIBS"
>  AC_SUBST(LIBS)
> -FINAL_CFLAGS="$TCFLAGS"
> +FINAL_CFLAGS="$TCFLAGS $PROCESSOR_FLAGS"
>  AC_SUBST(FINAL_CFLAGS)
> -CFLAGS="$TCFLAGS $TO3FLAGS -I\$(GCLDIR)/o"
> +CFLAGS="$TCFLAGS $TO3FLAGS $PROCESSOR_FLAGS -I\$(GCLDIR)/o"
>  AC_SUBST(CFLAGS)
>  O3FLAGS=$TO3FLAGS
>  AC_SUBST(O3FLAGS)
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]