octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's appropriate for the default branch?


From: Rik
Subject: Re: What's appropriate for the default branch?
Date: Fri, 29 Nov 2013 18:42:08 -0800

On 11/29/2013 05:29 PM, John W. Eaton wrote:
> On 11/29/2013 07:11 PM, Rik wrote:
>
>> I agree that the stable branch should remain slow-to-change and no
>> significant development work (GUI or otherwise) should take place there.
>> As for the the other, I like the simplicity of ping/ponging between a
>> stable and a development branch and would be just as happy without a third
>> GUI branch.  In my experience the default branch has not been wildly
>> experimental.  Except for a few days spread over the years, one could
>> always just do an 'hg pull; bootstrap; config; make' cycle and have it
>> work.  I could see isolating the GUI work if we thought that other changes
>> were going to de-stabilize the source tree to such a degree that it might
>> not be releasable in 6 months, but that hasn't been the past history of the
>> archive.
>
> My impression is that we are rarely ready for release.  When we
> announce that we are about to release, everyone suddenly shows up with
> a bunch of "must fix" bug reports and it takes us months to actually
> make a release.
I think a lot of the "must fix" bugs were related to the GUI.  If we had
simply acknowledged in our heart of hearts that the GUI wasn't ready for
this release cycle we could have moved on and produced 3.8 in a relatively
short time.  So, I'll still maintain that I usually find the development
branch close to release-worthy.
>
> I'm not sure what the solution to this problem is.  More frequent
> regular releases regardless of whether some big new feature like the
> GUI or classdef is really finished?
This is very modern, a la Chrome, but I dislike it.  Why waste people's
time downloading something that provides an infinitesimal improvement? 
When we have something good that people would benefit from, then we should
release it, but not simply because 42 days have passed.
>   Maintaining a
> "we-could-release-from-this-at-any-time" branch that is not open for
> changes unless tehy are truly finished and well tested?
We could try it.  It will be complicated, however, to remember which
changesets have been cherrypicked into the release branch and which have
not when we do a substantial release.  Mercurial might have ways of
alleviating that though.
>
> I'm not thrilled about having a lot of branches, but in this
> particular case I think it makes sense to have the separate branch for
> the 4.0 with the GUI for real release.  I would just do that work on
> stable but I'm thinking that it will take long enough to get 4.0 ready
> that we may need to make another 3.8.x release.
I think that working on stable is bad, so I will be fine with any plan that
avoids that.
>
>> Now maybe the changes on the classdef branch do represent such a
>> change, but if they are more than 6 months from finalization then maybe
>> they should just continue to live on their own separate named branch rather
>> than hijacking the default branch.
>
> If we do that, then I think classdef doesn't get much testing.
This is a classic chicken and egg problem.  You don't want to even bring
the classdef branch on to default unless it has a minimum level of
functionality and robustness, but the robustness can't be tested until it
is brought into wider usage.  Is classdef support in Octave going to occur
in the 4.X series or 5.X series?  If it is a goal for release 4.4 or 4.6 I
would still say it is too early to bring it on to default.

These are only my opinions.  I really will be fine with whatever strategy
we take.  Also, I'm not much of a GUI programmer so I will still end up
spending my time either on the stable or default branches.

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]