feature freeze for 3.2 release?

[John W. Eaton-3]

I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
focus primarily on testing and fixing any bugs that turn up.  Then
I'll branch for the release, make another snapshot or two, and then
make the release.  Perhaps that can happen by the middle of March.

Are there any objections to this plan?

I'll start by making a new snapshot today or tomorrow.  Are there any
outstanding changesets or any serious bugs that should be considered
before I make the snapshot?

jwe

[Thomas Treichl]

John W. Eaton schrieb:

> I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
> focus primarily on testing and fixing any bugs that turn up.  Then
> I'll branch for the release, make another snapshot or two, and then
> make the release.  Perhaps that can happen by the middle of March.
>
> Are there any objections to this plan?
>
> I'll start by making a new snapshot today or tomorrow.  Are there any
> outstanding changesets or any serious bugs that should be considered
> before I make the snapshot?

I'd like to configure the next snapshot on MacOSX with "--without-x" because we
can use your Carbon port instead. "--without-x" currently doesn't set up
includes and libraries correctly. I already sent a changeset but I don't know if
it is ok or not?

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010560.html

Please also consider this one:

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-February/010650.html

Thanks in advance,

   Thomas

[Ben Abbott]

On Feb 16, 2009, at 4:11 PM, John W. Eaton wrote:

> I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
> focus primarily on testing and fixing any bugs that turn up.  Then
> I'll branch for the release, make another snapshot or two, and then
> make the release.  Perhaps that can happen by the middle of March.
>
> Are there any objections to this plan?
>
> I'll start by making a new snapshot today or tomorrow.  Are there any
> outstanding changesets or any serious bugs that should be considered
> before I make the snapshot?
>
> jwe

I have one or two gnuplot related changes I'd like to have put in place.

(1) Currently when running gnuplot 4.3, gnuplot_drawnow uses the  
figure position property to reset any figure movements via the mouse.  
To avoid this nuisance, the previous position property value is stored  
in an empty/hidden text object, similar to what David did for plotyy,  
and the figure position info is only passed onto gnuplot when the user  
changes the position property.

(2) Add the ability to determine the actual x11 terminal position and  
pass the info back to the figure's position property. I have some  
experimental code working, but it presently relies upon 'xwininfo'. In  
addition, the update only occurs when gnuplot_drawnow is called. This  
change deserves some discussion and maybe some likely attention before  
being committed.

Ben

[Søren Hauberg]

man, 16 02 2009 kl. 16:11 -0500, skrev John W. Eaton:
> I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
> focus primarily on testing and fixing any bugs that turn up.  Then
> I'll branch for the release, make another snapshot or two, and then
> make the release.  Perhaps that can happen by the middle of March.
>
> Are there any objections to this plan?

I think this sounds like a very good plan. I'd like to see 3.2 released
in the not so distant future.

> I'll start by making a new snapshot today or tomorrow.  Are there any
> outstanding changesets or any serious bugs that should be considered
> before I make the snapshot?

1) The comments

#    if (exist (name, "file"))
#      delete (name);
#    endif

in the end of 'makeinfo.m' should not be comments. We agreed on this
change, but I'm unsure of when I can push changes, so I haven't done
anything.

2) If 'makeinfo.m' should be renamed to '__makeinfo__.m', I'd like to
see this happen before a release is made. Then I can release software
that uses this function, and I won't have to make a new release shortly
after when 'makeinfo.m' is renamed. I don't mind making such changes,
but I'm unsure of when I can push a change.

Other than that, I don't have anything, and I see no failures in 'make
check'.

Søren

>
> jwe

[John W. Eaton-3]

On 16-Feb-2009, Søren Hauberg wrote:

| man, 16 02 2009 kl. 16:11 -0500, skrev John W. Eaton:
| > I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
| > focus primarily on testing and fixing any bugs that turn up.  Then
| > I'll branch for the release, make another snapshot or two, and then
| > make the release.  Perhaps that can happen by the middle of March.
| >
| > Are there any objections to this plan?
|
| I think this sounds like a very good plan. I'd like to see 3.2 released
| in the not so distant future.
|
| > I'll start by making a new snapshot today or tomorrow.  Are there any
| > outstanding changesets or any serious bugs that should be considered
| > before I make the snapshot?
|
| 1) The comments
|
| #    if (exist (name, "file"))
| #      delete (name);
| #    endif
|
| in the end of 'makeinfo.m' should not be comments. We agreed on this
| change, but I'm unsure of when I can push changes, so I haven't done
| anything.
|
| 2) If 'makeinfo.m' should be renamed to '__makeinfo__.m', I'd like to
| see this happen before a release is made. Then I can release software
| that uses this function, and I won't have to make a new release shortly
| after when 'makeinfo.m' is renamed. I don't mind making such changes,
| but I'm unsure of when I can push a change.

I checked in a fix for both of these items.  If there are other
problems, go ahead an fix them and check in the change.

Thanks,

jwe

[Thomas Treichl]

John W. Eaton schrieb:

> I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
> focus primarily on testing and fixing any bugs that turn up.  Then
> I'll branch for the release, make another snapshot or two, and then
> make the release.  Perhaps that can happen by the middle of March.
>
> Are there any objections to this plan?
>
> I'll start by making a new snapshot today or tomorrow.  Are there any
> outstanding changesets or any serious bugs that should be considered
> before I make the snapshot?

Please find attached a changeset that documents the framework configure options
that have been added recently.

Best regards,

   Thomas

# HG changeset patch
# User Thomas Treichl <Thomas.Treichl@...>
# Date 1234902300 -3600
# Node ID 4d5da33596c6251c18f0275bad965329a9d85cf2
# Parent  45524925bed9054531132c2ef45ff620435674ba
Add documentation for configure options "--without-framework-carbon" and "--without-framework-opengl".

diff --git a/doc/ChangeLog b/doc/ChangeLog
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,8 @@
[phone]  Thomas Treichl  <Thomas.Treichl@...>
+
+ * interpreter/install.txi: Add documentation for configure options
+ "--without-framework-carbon" and "--without-framework-opengl".
+
 2009-02-11  John W. Eaton  <jwe@...>
 
  * interpreter/Makefile.in (uninstall): Use $(DESTDIR) here too.
diff --git a/doc/interpreter/install.txi b/doc/interpreter/install.txi
--- a/doc/interpreter/install.txi
+++ b/doc/interpreter/install.txi
@@ -148,6 +148,19 @@
 libraries that cause problems for some reason.  You can also use
 @code{--with-blas=lib} to specify a particular BLAS library
 @code{-llib} that configure doesn't check for automatically.
+
+@item --without-framework-carbon
+Don't use framework Carbon headers, libraries and specific source code
+for compilation even if the configure test succeeds (the default value
+is @code{--with-framework-carbon}). This is a platform specific configure
+option for Mac systems.
+
+@item --without-framework-opengl
+Don't use framework OpenGL headers, libraries and specific source code
+for compilation even if the configure test succeeds. If this option is
+given then OpenGL headers and libraries in standard system locations are
+tested (the default value is @code{--with-framework-opengl}). This is a
+platform specific configure option for Mac systems.
 
 @item --help
 Print a summary of the options recognized by the configure script.

[John W. Eaton-3]

On 17-Feb-2009, Thomas Treichl wrote:

| John W. Eaton schrieb:
| > I'd like to have a short feature freeze (perhaps 2-3 weeks) while we
| > focus primarily on testing and fixing any bugs that turn up.  Then
| > I'll branch for the release, make another snapshot or two, and then
| > make the release.  Perhaps that can happen by the middle of March.
| >
| > Are there any objections to this plan?
| >
| > I'll start by making a new snapshot today or tomorrow.  Are there any
| > outstanding changesets or any serious bugs that should be considered
| > before I make the snapshot?
|
| Please find attached a changeset that documents the framework configure options
| that have been added recently.

I applied it.

Thanks,

jwe