[Top][All Lists]
[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
- Re: [Gcl-devel] compile-file question, Vadim V. Zhytnikov, 2003/09/01
- [Gcl-devel] 2.6.1, Camm Maguire, 2003/09/03
- Re: [Gcl-devel] 2.6.1, David MENTRE, 2003/09/04
- Re: [Gcl-devel] 2.6.1, Vadim V. Zhytnikov, 2003/09/04
- Re: [Gcl-devel] 2.6.1, Camm Maguire, 2003/09/04
- Re: [Gcl-devel] 2.6.1, Camm Maguire, 2003/09/05
- Re: [Gcl-devel] 2.6.1, Vadim V. Zhytnikov, 2003/09/06
- Re: [Gcl-devel] 2.6.1, Camm Maguire, 2003/09/08
- Re: [Gcl-devel] 2.6.1, Vadim V. Zhytnikov, 2003/09/09
- Re: [Gcl-devel] 2.6.1,
Camm Maguire <=