Re: policy for release branch

[Jaroslav Hajek]

On Thu, Jun 11, 2009 at 9:33 PM, John W. Eaton<address@hidden> wrote:
> 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.
>

OK, that's true. I think problems started when I went transplanting
some of the graphics improvements.

> | 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.

An example is the recent fixes for overloaded class indexing &
cs-lists. The problem was not really a regression, since classes are
new stuff, but does not quite work, even though maybe it was supposed
to. 3.2.0 also broke the octcdf package, but apparently that only
previously worked because of bugs in 3.0.x.

> | 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.

Hm. So we should assume the worst, I think. But I guess there is no
way to verify the ABI did not change?

> | 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.
>

Interesting. I never imagined sources are downloaded that often.

> 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.

I'm mostly interested in programming, especially Octave's computing
capabilities. If you recall, one of my motivations to take the release
manager role was to get more experience with mercurial. The problem
was that as the gap between development and 3.0.x branch widened, I
was gradually losing interest in the 3.0.x branch, which eventually
made me quite a lousy manager.

> | 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.

Hm. Maybe we could make more frequent snapshots from the development
branch, and really keep the stable branch down? What did it take to
make the 3.1.55 or 3.1.54 snapshots?

> 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?

Well, that's 100% correct.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz