Re: Integrating Quint into the Octave sources

[John W. Eaton]

On 18-Apr-2011, Jordi Gutiérrez Hermoso wrote:

| I think we've had a long history of this approach which fails for
| sociological reasons. Do we really need another QtOctave, another
| XOctave, another GUIOctave, another Octave Workshop? Compare with the
| case of octplot, plplot, Octaviz, yapso, and whatever else and the
| much more evident success of the fltk backend.
| 
| If it's all in one place, if we're all looking at the same code, if
| every user who doesn't give configure a --without-gui option is
| building the software, it is much more likely to become something that
| we can all enjoy.

| Then what's the collaborative development location for having software
| that is known to be possibly broken? We need such a location. If we
| all kept our software locked up without sharing it centrally until it
| was perfect for a release, no collaboration would ever take place.

I completely agree with Jordi on both of these points.

If the GUI (or some other experimental new feature) is too risky for
immediate integration on the default branch, but large enough that it
will take some time to work out the kinks and would benefit from
multiple people looking at it regularly, then we can always create
another branch just for the new feature.  That branch would
periodically be merged with default so that it will not diverge too
much from the core sources.  That seems much less likely to happen if
the code is developed separately.  Merging later will almost certainly
be much more difficult than merging now.

jwe