Release Ideas

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Release Ideas

John W. Eaton
Administrator
It's been a long time since 3.8.0.

What's required for the gui-release branch to be released?  My list
really only has

   Use Qt widgets for plotting with the GUI

I've been working a little bit on adding buttons and making zooming work
with the mouse wheel.  I hope to push some changes for those things
later this week.

Beyond that, I think the GUI is in pretty good shape.  Sure, a lot of
issues have been reported, but I think it is more than usable at this point.

I'd like to follow that release relatively soon with a release from what
is now the default branch because it has a lot more bug fixes that
should probably be in a released version of Octave.

What show-stopping bugs need to be fixed on either branch before we make
a release?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Philip Nienhuis
John W. Eaton wrote
It's been a long time since 3.8.0.

What's required for the gui-release branch to be released?  My list
really only has

   Use Qt widgets for plotting with the GUI

I've been working a little bit on adding buttons and making zooming work
with the mouse wheel.  I hope to push some changes for those things
later this week.
I haven't used the qt toolkit a lot as a number of things do not work yet; panning is one of them.
But qt seems to work a lot faster and smoother than fltk.

Beyond that, I think the GUI is in pretty good shape.  Sure, a lot of
issues have been reported, but I think it is more than usable at this point.
It absolutely is.

I'd like to follow that release relatively soon with a release from what
is now the default branch because it has a lot more bug fixes that
should probably be in a released version of Octave.

What show-stopping bugs need to be fixed on either branch before we make
a release?
A serious issue for me is the OpenGL single precision. I often work with time series from the late 19th century to date (datenum order ~ 733000) and those time series get severely distorted due to insufficient precision.  See bugs #40246, #33748 and #32980.

Default: as long as classdef is still experimental, not much.
Support for I/O of classdef objects in .mat files would be wonderful when classdef gets more mature. But of course that's the wish list, not a showstopper bug.

A while ago you mentioned you'd liked to have xlsread & xlswrite in core Octave. I'm almost ready to amend the io package to make that happen, but I could use some guidance; I've made some remarks and asked some questions in the thread in question (http://octave.1599824.n4.nabble.com/Spreadsheet-support-in-core-Octave-instead-of-io-package-tt4666947.html#a4666962). One is what parts can go to core Octave first, what parts can follow later and what parts should rather stay in the io package.
Plus of course, from the POV of a package maintainer, how to manage io package support for the then newest and older versions of Octave.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Michael Godfrey
In reply to this post by John W. Eaton

On 01/27/2015 04:23 PM, John W. Eaton wrote:
It's been a long time since 3.8.0.

What's required for the gui-release branch to be released?  My list really only has

  Use Qt widgets for plotting with the GUI

I've been working a little bit on adding buttons and making zooming work with the mouse wheel.  I hope to push some changes for those things later this week.

Beyond that, I think the GUI is in pretty good shape.  Sure, a lot of issues have been reported, but I think it is more than usable at this point.

I'd like to follow that release relatively soon with a release from what is now the default branch because it has a lot more bug fixes that should probably be in a released version of Octave.

What show-stopping bugs need to be fixed on either branch before we make a release?

jwe

As you would expect, I agree that releases soon would be good. I normally use the default branch and
have no problems with it at present.  It would be nice if JIT compiled again, but it was never really
ready for release. I do not know of any blocking problems with the default. So, it is not obvious that a
GUI release before default release really makes sense. 

Unless there is something blocking default, why not just make one release (default already has all the
GUI code).
Pilip mentioned:
A serious issue for me is the OpenGL single precision. I often work with
time series from the late 19th century to date (datenum order ~ 733000) and
those time series get severely distorted due to insufficient precision.  See
bugs #40246, #33748 and #32980.
But, this is true of all the branches, sorry to say.

Michael
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by Philip Nienhuis
On 01/27/2015 06:26 PM, Philip Nienhuis wrote:

> A while ago you mentioned you'd liked to have xlsread & xlswrite in core
> Octave.

Yes, that would be a good addition.  Thanks.

 > I'm almost ready to amend the io package to make that happen, but I
> could use some guidance; I've made some remarks and asked some questions in
> the thread in question
> (http://octave.1599824.n4.nabble.com/Spreadsheet-support-in-core-Octave-instead-of-io-package-tt4666947.html#a4666962).

OK, I'll follow up there.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by Michael Godfrey
On 01/27/2015 06:40 PM, Michael Godfrey wrote:

> Unless there is something blocking default, why not just make one
> release (default already has all the
> GUI code).

We deprecated some things in 3.8 that have already been removed from
default but not gui-release.  Normally we have one release that still
contains the deprecated functions but warns if they are used.  Skipping
the gui-release release and going straight to default would break this
promise that we normally make.  Not a huge thing, I suppose, but
something we should consider if we decide to just release default.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Michael Godfrey

On 01/27/2015 07:35 PM, John W. Eaton wrote:

> On 01/27/2015 06:40 PM, Michael Godfrey wrote:
>
>> Unless there is something blocking default, why not just make one
>> release (default already has all the
>> GUI code).
>
> We deprecated some things in 3.8 that have already been removed from
> default but not gui-release.  Normally we have one release that still
> contains the deprecated functions but warns if they are used.  
> Skipping the gui-release release and going straight to default would
> break this promise that we normally make.  Not a huge thing, I
> suppose, but something we should consider if we decide to just release
> default.
>
> jwe
>
That is a concern. But, it might make sense to amend the deprecated
functions rule to 1 release or some
substantial length of time since the deprecated announcement.
A compromise might be to make the GUI  branch at the point it is closed
available for download for anyone who depends on the deprecated
functions, but go ahead with the
"official" release of the default. This would make the benefits of the
default available and close down
the 2 versions under development problem.

I am confident that practically all users will be happier with the
default branch.

Michael


Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

siko1056
Michael Godfrey wrote
I am confident that practically all users will be happier with the
default branch.
Agree. I work on the default branch for more than a year, and I am really happy with it. The GUI is already in a very useful shape.

Kai
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Giuseppe Molica
In reply to this post by Michael Godfrey
>
>>I am confident that practically all users will be happier with the
>>default branch.
>

As user, I agree with you.

PS: hello everybody, I'm a Software Engineering student who is studying
the Octave source to understand how can help you in the development. :-)
--
Giuseppe Molica

Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Carnë Draug
In reply to this post by John W. Eaton
On 27 January 2015 at 21:23, John W. Eaton <[hidden email]> wrote:
> It's been a long time since 3.8.0.
>
> What's required for the gui-release branch to be released?  My list really
> only has
>
> [...]
>
> What show-stopping bugs need to be fixed on either branch before we make a
> release?

I though that the plan for the 4.0.0 release was also to distribute official
binaries for Windows and Mac.  Is this still part of the plan?  I was under
the impression that this was going well for Windows at least.

On 28 January 2015 at 00:35, John W. Eaton <[hidden email]> wrote:

> On 01/27/2015 06:40 PM, Michael Godfrey wrote:
>
>> Unless there is something blocking default, why not just make one
>> release (default already has all the
>> GUI code).
>
> We deprecated some things in 3.8 that have already been removed from default
> but not gui-release.  Normally we have one release that still contains the
> deprecated functions but warns if they are used.  Skipping the gui-release
> release and going straight to default would break this promise that we
> normally make.

Making two separate releases with a small time interval between them just to
keep this promise will be the same as breaking it.  I feel that the promise
behind the two releases is about the time.  Doing this is just breaking the
"spirit of the law".

I still think that merging the gui-release and default into a single release
may be a good idea.  We can just bring back the removed functions from the
history and remove them on the following release instead.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John Donoghue-3
In reply to this post by John W. Eaton
>
> Message: 3
> Date: Tue, 27 Jan 2015 16:23:25 -0500
> From: "John W. Eaton" <[hidden email]>
> To: Octave Maintainers <[hidden email]>
> Subject: Release Ideas
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> It's been a long time since 3.8.0.
>
> What's required for the gui-release branch to be released?  My list really
only
> has
>
>    Use Qt widgets for plotting with the GUI
>
> I've been working a little bit on adding buttons and making zooming work
with
> the mouse wheel.  I hope to push some changes for those things later this
week.
>
> Beyond that, I think the GUI is in pretty good shape.  Sure, a lot of
issues have
> been reported, but I think it is more than usable at this point.
>
> I'd like to follow that release relatively soon with a release from what
is now the
> default branch because it has a lot more bug fixes that should probably be
in a
> released version of Octave.
>
> What show-stopping bugs need to be fixed on either branch before we make a
> release?
>
> jwe
>

Not sure if it falls under Qt plotting but including printing using the Qt
widgets rather than having to switch toolkits would be nice.
https://savannah.gnu.org/bugs/index.php?42537




Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by Carnë Draug
On 01/28/2015 08:19 AM, Carnë Draug wrote:

> I though that the plan for the 4.0.0 release was also to distribute official
> binaries for Windows and Mac.  Is this still part of the plan?  I was under
> the impression that this was going well for Windows at least.

Yes.  I think we have Windows mostly handled at this point, though there
will be some details to take care of, like dealing with the sources so
that we properly comply with the GPL for our binary release.  I don't
know what to do about OS X except to say that it is not an officially
supported platform, at least until someone steps forward and can do the
work to provide some kind of easy-to-install binary package.  My
apologies if this has already happened as I'm not aware of one.

> Making two separate releases with a small time interval between them just to
> keep this promise will be the same as breaking it.  I feel that the promise
> behind the two releases is about the time.  Doing this is just breaking the
> "spirit of the law".

I don't see it that way.  The gui-release version would be available for
those people who still need the deprecated functions that have been
removed from default.

> I still think that merging the gui-release and default into a single release
> may be a good idea.  We can just bring back the removed functions from the
> history and remove them on the following release instead.

I would really prefer to not have to do that work just to keep a
"promise" that we imposed on ourselves.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by John Donoghue-3
On 01/28/2015 08:31 AM, JohnD wrote:

> Not sure if it falls under Qt plotting but including printing using the Qt
> widgets rather than having to switch toolkits would be nice.
> https://savannah.gnu.org/bugs/index.php?42537

Yes, this should definitely be fixed if using the qt widgets for
plotting is the default.

Such apparent anger in that bug report too.  Hmm.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Mike Miller
In reply to this post by John W. Eaton
On Tue, Jan 27, 2015 at 16:23:25 -0500, John W. Eaton wrote:

> It's been a long time since 3.8.0.
>
> What's required for the gui-release branch to be released?  My list really
> only has
>
>   Use Qt widgets for plotting with the GUI
>
> I've been working a little bit on adding buttons and making zooming work
> with the mouse wheel.  I hope to push some changes for those things later
> this week.
>
> Beyond that, I think the GUI is in pretty good shape.  Sure, a lot of issues
> have been reported, but I think it is more than usable at this point.
>
> I'd like to follow that release relatively soon with a release from what is
> now the default branch because it has a lot more bug fixes that should
> probably be in a released version of Octave.
>
> What show-stopping bugs need to be fixed on either branch before we make a
> release?

I agree, FWIW. I have not been using the gui-release branch as much as
I would like, but it seems to me like it is in very good shape for a
release. And the Windows binary task seems like it is in good shape
too, just from what I've seen observing the lists and bug reports.
Releasing a more stable GUI and an official Window binary were the
main release goals for 4.0.

I think it's important that we do release 4.0 from the gui-release
branch, followed by 4.2 from the default branch, as we originally had
planned. If the schedule changes, so be it, but the version numbers
are meaningful and the two branches are providing different stages of
improvements.

Bug #41819 should definitely be addressed for 4.0. I see there is a
patch to be tested, I'll try it on my setup.

I would like to revisit bug #37062 for 4.0, but this is more of a QA
bug related to the GUI, definitely not a blocker.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John Swensen-3
In reply to this post by John W. Eaton

On Jan 28, 2015, at 12:04 PM, John W. Eaton <[hidden email]> wrote:

> On 01/28/2015 08:19 AM, Carnë Draug wrote:
>
>> I though that the plan for the 4.0.0 release was also to distribute official
>> binaries for Windows and Mac.  Is this still part of the plan?  I was under
>> the impression that this was going well for Windows at least.
>
> Yes.  I think we have Windows mostly handled at this point, though there will be some details to take care of, like dealing with the sources so that we properly comply with the GPL for our binary release.  I don't know what to do about OS X except to say that it is not an officially supported platform, at least until someone steps forward and can do the work to provide some kind of easy-to-install binary package.  My apologies if this has already happened as I'm not aware of one.
>

I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

and then type:
brew tap homebrew/science
brew install gfortran
brew update && brew upgrade
brew install gcc
brew install octave

I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"

John S.
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Jordi Gutiérrez Hermoso-2
On Wed, 2015-01-28 at 14:50 -0500, John Swensen wrote:
> I know it is a cop-out, but is it really too hard to ask people to
> go to a terminal and type:

Yes, it is too hard. This implicitly assumes that people have their OS
in a particular state before the first curl command. I have seen
people attempt this and suffer many, many woes when their system was
not in that state.

Not to mention, that you also need to first explain to them that their
OS has a terminal and that it's a place in which you can type
commands. It is just a very foreign idea to most Mac OS X users.

- Jordi G. H.





Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

John W. Eaton
Administrator
In reply to this post by John Swensen-3
On 01/28/2015 02:50 PM, John Swensen wrote:

> I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:

Yeah, I suspect it is.

> ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
>
> and then type:
> brew tap homebrew/science
> brew install gfortran
> brew update && brew upgrade
> brew install gcc
> brew install octave
>
> I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"

How long does this process take for someone who is installing everything
for the first time?

Even if you scripted this and put a pretty GUI "one-click" installer
around it, I suspect most users would find it annoying that it takes
possibly hours to install while the system is quite busy.

Also, if it is this simple to build Octave from homebrew, why do we see
so many people complaining about how hard it is to build Octave for OS X?

Finally, if it is this simple, then why hasn't anyone turned the
resulting binaries into a simple installer?  Is that part difficult?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Michael Godfrey

On 01/28/2015 03:24 PM, John W. Eaton wrote:
> On 01/28/2015 02:50 PM, John Swensen wrote:
>
>> I know it is a cop-out, but is it really too hard to ask people to go
>> to a terminal and type:
>
> Yeah, I suspect it is.
Definitely too hard. As Jordi said many Mac users do not know what a
"command window" is.
And, they are unlikely to learn just for Octave.

Another point about 1 or 2 releases: there is quite a lot of downstream
work to get
new versions into the various distributions. Asking the people who do
this work to
do it for the GUI and then very soon do it all again for the default
(4.2?) should be
avoided if possible. And, handling bug reports for the GUI and 4.2 for
an extended
period will be an added burden on everyone.

So, serious thought about a single release seems a good idea.

Michael


Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

bpabbott
Administrator
In reply to this post by John W. Eaton
> On Jan 28, 2015, at 3:24 PM, John W. Eaton <[hidden email]> wrote:
>
> On 01/28/2015 02:50 PM, John Swensen wrote:
>
>> I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:
>
> Yeah, I suspect it is.
>
>> ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
>>
>> and then type:
>> brew tap homebrew/science
>> brew install gfortran
>> brew update && brew upgrade
>> brew install gcc
>> brew install octave
>>
>> I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"
>
> How long does this process take for someone who is installing everything for the first time?
>
> Even if you scripted this and put a pretty GUI "one-click" installer around it, I suspect most users would find it annoying that it takes possibly hours to install while the system is quite busy.
>
> Also, if it is this simple to build Octave from homebrew, why do we see so many people complaining about how hard it is to build Octave for OS X?

I think the biggest hurdle for Mac OSX is that Yosemite's clang has broken a some things. Both Fink and Macports are now able to build 3.8.2 on Yosemite, but those solutions do not work for me using the default branch. My impression (and not a reliable one) is that I'll need clang 6 before a build can be successful..

> Finally, if it is this simple, then why hasn't anyone turned the resulting binaries into a simple installer?  Is that part difficult?

That would be easy, but Octave would end up installed in the directory structure reserved for Homebew, Macports, or Fink.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

bpabbott
Administrator
> On Jan 28, 2015, at 3:54 PM, Marius Schamschula <[hidden email]> wrote:
>
> On Jan 28, 2015, at 2:48 PM, Ben Abbott <[hidden email]> wrote:
>
>>> On Jan 28, 2015, at 3:24 PM, John W. Eaton <[hidden email]> wrote:
>>>
>>> On 01/28/2015 02:50 PM, John Swensen wrote:
>>>
>>>> I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:
>>>
>>> Yeah, I suspect it is.
>>>
>>>> ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
>>>>
>>>> and then type:
>>>> brew tap homebrew/science
>>>> brew install gfortran
>>>> brew update && brew upgrade
>>>> brew install gcc
>>>> brew install octave
>>>>
>>>> I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"
>>>
>>> How long does this process take for someone who is installing everything for the first time?
>>>
>>> Even if you scripted this and put a pretty GUI "one-click" installer around it, I suspect most users would find it annoying that it takes possibly hours to install while the system is quite busy.
>>>
>>> Also, if it is this simple to build Octave from homebrew, why do we see so many people complaining about how hard it is to build Octave for OS X?
>>
>> I think the biggest hurdle for Mac OSX is that Yosemite's clang has broken a some things. Both Fink and Macports are now able to build 3.8.2 on Yosemite, but those solutions do not work for me using the default branch. My impression (and not a reliable one) is that I'll need clang 6 before a build can be successful..
>>
>>> Finally, if it is this simple, then why hasn't anyone turned the resulting binaries into a simple installer?  Is that part difficult?
>>
>> That would be easy, but Octave would end up installed in the directory structure reserved for Homebew, Macports, or Fink.
>
> Not necessarily. Years ago when we built the OS X version of CISM_DX, see <http://cism.hao.ucar.edu/cismdx/install.htm>, we built octave using MacPorts, but installed it into a custom path.
>
> Marius

I've done that myself. I even modified it to install as a relocatable bundle ... but it wasn't an easy task. If we don't make it relocatable, is there a way to enure there isn't a conflict?

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Release Ideas

Marius Schamschula-5

On Jan 28, 2015, at 3:00 PM, Ben Abbott <[hidden email]> wrote:

>> On Jan 28, 2015, at 3:54 PM, Marius Schamschula <[hidden email]> wrote:
>>
>> On Jan 28, 2015, at 2:48 PM, Ben Abbott <[hidden email]> wrote:
>>
>>>> On Jan 28, 2015, at 3:24 PM, John W. Eaton <[hidden email]> wrote:
>>>>
>>>> On 01/28/2015 02:50 PM, John Swensen wrote:
>>>>
>>>>> I know it is a cop-out, but is it really too hard to ask people to go to a terminal and type:
>>>>
>>>> Yeah, I suspect it is.
>>>>
>>>>> ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
>>>>>
>>>>> and then type:
>>>>> brew tap homebrew/science
>>>>> brew install gfortran
>>>>> brew update && brew upgrade
>>>>> brew install gcc
>>>>> brew install octave
>>>>>
>>>>> I know this is a bit harder, but for a "unsupported" platform it is still quite easy. The only issue is that for the homebrew recipe that the gui is not the default and you have to run "octave --force-gui"
>>>>
>>>> How long does this process take for someone who is installing everything for the first time?
>>>>
>>>> Even if you scripted this and put a pretty GUI "one-click" installer around it, I suspect most users would find it annoying that it takes possibly hours to install while the system is quite busy.
>>>>
>>>> Also, if it is this simple to build Octave from homebrew, why do we see so many people complaining about how hard it is to build Octave for OS X?
>>>
>>> I think the biggest hurdle for Mac OSX is that Yosemite's clang has broken a some things. Both Fink and Macports are now able to build 3.8.2 on Yosemite, but those solutions do not work for me using the default branch. My impression (and not a reliable one) is that I'll need clang 6 before a build can be successful..
>>>
>>>> Finally, if it is this simple, then why hasn't anyone turned the resulting binaries into a simple installer?  Is that part difficult?
>>>
>>> That would be easy, but Octave would end up installed in the directory structure reserved for Homebew, Macports, or Fink.
>>
>> Not necessarily. Years ago when we built the OS X version of CISM_DX, see <http://cism.hao.ucar.edu/cismdx/install.htm>, we built octave using MacPorts, but installed it into a custom path.
>>
>> Marius
>
> I've done that myself. I even modified it to install as a relocatable bundle ... but it wasn't an easy task. If we don't make it relocatable, is there a way to enure there isn't a conflict?
>
> Ben

Well, the GUI icon can be put anywhere within the Applications folder (e.g. the MacPorts subfolder on my machines), as long as it correctly points to the octave hierarchy (which shouldn’t be /opt/local, /usr/local or /sw for obvious reasons). For CISM_DX we used /usr/local/CISM_DX and had the whole tree of OpenDX and octave with all their supporting libraries under that. I’ve never messed with building relocatable bundles - that’s really the hard part when you don’t build using Xcode.

Marius
--
Marius Schamschula





123