[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: VisualGST
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: VisualGST |
Date: |
Sun, 13 Jun 2010 14:04:46 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Thunderbird/3.0.4 |
On 06/13/2010 01:06 PM, Gwenael Casaccio wrote:
3) GIT:
The state of my git branch is simple, I don't work on stable and don't merge
on it and probably won't do it. Instead of merging visualgst in gst, we could
use gst-package --download to update it and download the latest version.
Sorry, I disagree with this. There's only three ways to ensure that the
GST-bundled VisualGST is stable:
1) provide a stable branch that GST can reliably sync with every now and
then;
2) do all development on topic branches and merge them only when they
are _rock solid_;
3) synchronize stabilization of GST and VisualGST.
You didn't do (3) for 3.2 (and it doesn't make sense, the stabilization
periods of GST is too long). You don't do (2). So the stable branch is
the only possibility.
In addition to this, VisualGST up to not-long-ago was still relying on
the very latest infrastructure in GTK+ bindings. This has stabilized
now but, if we had reasons to start doing that again, it would be really
necessary to provide a stable branch that can work with the GTK+
bindings in the latest released GST.
(Why? Because we cannot afford again saying "use the git version"
for 2 years. The development of GST should focus on getting it in
all the distributions, including Debian, Fedora, fink, MacPorts.
Which is totally unfun work, but has to be done).
It's not hard to do. When you're bugfixing, you bugfix from stable and
merge stable into master. When your stabilization period is over, you
merge master into stable. That's it.
4) Patch:
The patch of Paolo is welcome like any patch, frankly speaking I was a bit
frustrated not by the patch but I know that I've spent a lot of time to make a
descent design and code quality (as an humble and alone developer) and I've
worked a lot on it.
I don't think there's anything to be frustrated about. Certainly I
didn't write the patch in anger, and none of my remarks were meant to be
criticisms of the design. Instead, I wanted to overview best practices
for future patches to VisualGST, based on my experience of a few hours.
Another sidebar: it's hard to understand without seeing the code
that VisualGST is much more than the browser; everybody can code
that.
The difficult part of VisualGST is the code that allows you to
implement the browser as _good_ Smalltalk code. If you think about
it in MVC terms, GTK+ provides you with the view and a C interface
to the model. The Smalltalk wrappers to the models, and especially
the controller hierarchy, are a big big part of VisualGST, and one
that you (Gwen) can only be proud of.
It's easy for people to overlook the complexity of VisualGST despite
being "only" 15k lines of code.
Now, if you want to do something else with GNU Smalltalk that's fine.
You put an incredible effort in VisualGST during the Summer of Code and
also afterwards. I am also glad sometimes that the VM is so stable :-)
that I can do something else, such as hacking on VisualGST or porting
fun stuff from Squeak. That I can just say "development of 3.3 is not
yet open, and I don't really care about new features". I wouldn't have
the energy to start working on a JIT compiler for example; heck, I don't
have the energy to fix the one that exists... (That also is a matter of
real life constraints of course, but that's not relevant now).
However, there was without doubt a communication problem and a
management problem before the release of 3.2. We should acknoledge that
(both you and me) so that we can cooperate better in the future.
Paolo