policy for release branch

[John W. Eaton]

On 11-Jun-2009, Jaroslav Hajek wrote:

| When a release is branched, what patches can go into the release
| branch? Unoficially, it should be bugfixes and docfixes, but this
| specification is still vague. Is missing Matlab
| functionality/compatibility a bug?

My experience has been that including missing features tends to cause
trouble, and takes time and energy away from development on the
trunk.  Also, if the trunk and branch have diverged, some new features
may not be possible to add.  Worse, it may not be obvious when subtle
problems will arise if a patch for a new feature is copied from the
trunk to the release branch.  It think we saw all of these problems in
the 3.0.x release branch.

| I think there was also a proposal to only fix regressions; but this
| doesn't work well when new & buggy features come out with a major
| release - surely we don't want to leave them buggy until another major
| release.

I would agree that it is not good to have bugs in the new features,
but whether they must be fixed in the stable release series depends on
how serious they are (is the "bug" just a missing feature, or does it
result in an incorrect answer?) and how complex the fix is (will it
result in a binary interface change?).

I guess I would be OK with aiming for fixing regressions and serious
bugs (incorrect answers or crashes) only.  Other changes could be
considered after some discussion.  Fixes for documentation are always
OK.

| Another point is about not breaking the binary interface between minor
| releases; this has some merit w.r.t. packages compatibility; however,
| what if an important bugfix is created that breaks the interface?
| Should it be left out? Or adapted? Who will do it?

It would be best to avoid breaking the interface if possible.  I
recall using different fixes for the same problem in the past so that
we could keep interfaces stable in the stable release series but fix
the bug properly in the trunk.

| Speaking about this, how does one tell whether the change breaks the
| binary compatibility? Modifying methods is sure; what about adding new
| ones? What about changing classes that are not marked as API - is that
| OK?

Changing internals should be OK.  Changing interfaces could cause
trouble.  Removing functions is likely to cause trouble.  Adding new
functions should be OK, but I'm not sure what happens if you add a new
virtual function to a class.

| Where it *can* compete, is that most reported bugs are fixed within a
| week, often just a day or two. Now this is, on the contrary, something
| Matlab can't compete with - you can get a fix very fast, or even an
| improvement or a new feature. This is, however, only true for that
| relatively small number of users compiling Octave from sources.

Is that number really small?  I still see Octave sources being
downloaded tens of thousands of times from ftp.octave.org for any
given release.  Maybe there are lots of people that are happily
building from sources?  Remember that we tend to only hear from people
when things don't work.  Rarely do we see people reporting that things
are working as expected.

I think you have to decide what you want your role to be.  Do you want
to make binary releases for people who can't figure out how to compile
a simple "hello world" program?  Or do you want to hack Octave and
leave the hand holding to someone else?  It seems to me that with your
talents, you should be hacking Octave, making patches and sources
available, and letting someone else deal with building binaries.

| Those
| who use, say, packages from a Linux distro, are limited by releases of
| Octave and package updates in the distro.

In the past when I was making more frequent snapshots, new Debian
packages were typically available for each new snapshot within a few
days.  But these were not "stable" releases, so often had problems.  I
guess if you want the latest, you have to be willing to put up with
some potential problems.

We have limited resources.  If people want things to improve, then let
them help out in some way.  Unless someone is paying for service, then
why is it a problem that we only provide sources, and then only on a
time schedule that suits us?

jwe