Re: Keeping the gui-release branch open considered harmful

[Daniel J Sebald]

On 01/30/2015 09:27 AM, John W. Eaton wrote:
> On 01/29/2015 09:21 PM, Michael Godfrey wrote:
>
> > I think that this makes clear that maintaining GUI and default is
> > causing a lot more problems
> > than it could possibly be worth. It is hard to imagine that doing a
> > final merge and work form there
> > would be harder than dealing with all the divergent problems of 2
> > branches.
>
> Any other comments on this, or should I just close the branch?

I haven't been following the branch development that closely as of late. 
 I'd say that if there are a lot of conflicts occurring with a merge 
then something probably is no longer organized in a meaningful way. 
Where are the conflicts occurring?  Are there elements of the GUI in 
both the GUI branch and the default branch?  There probably shouldn't 
be.  How about changes/fixes in the core code?  Those probably shouldn't 
be in the GUI branch, but only in the default branch.  A lot of the bug 
fixes in the default branch have little bearing on GUI development 
(e.g., one can do GUI development without a fix in the parser behavior 
no matter how critical that fix is to the overall project).

To me, branching is either for creating a whole new project (e.g., 
SeaMonkey from FireFox) or for something experimental that will last for 
a few weeks or months until it is stable and then be moved in or 
truncated if the concept doesn't work out as hoped.  (Whatever time 
frame it makes sense to maintain the separation.)  Moving bits and 
pieces across branches every once in a while is probably not good 
because in some sense it is a bit like trying to maintain a branch 
against an older version of itself.

In hindsight, a better model may have been to keep the GUI isolated to 
one branch and when it comes time to release a beta version of Octave 
with the GUI then do a merge of the two branches as a temporary offshoot 
of the GUI (i.e., a GUI beta version release would be a hybrid "stub" or 
"bud").  The same idea would have worked for Qt graphics.

Dan