[bt-devel] QtWebKit DOM access

[Eeli Kaikkonen]

Quoting Gary Holmlund <gary.holmlund at gmail.com>:

>
> I believe that using a branch for a 1.7 release is an independent
> decision from how to deal with the changes for QtWebkit. Even if we had
> a 1.7 branch and new development was happening on the HEAD, I would not
> directly check my changes into the HEAD. I believe the HEAD should be a
> close to stable as possible at all times. Otherwise my work would imped
> other development going onto the HEAD.
>
> So, I would need to do something such as using #if or using a personal
> svn branch or use a private source code control. Using the #if has the
> advantage that others can see the work and comment on it or even
> contribute to it. With the change of the #define anyone could compile
> the QtWebkit version. The #if could stay until new feature is
> considered stable and then old code could be removed.
>

Let's take this #ifdef path then. Just give a short explanation how
developers can turn this on/off, preferably by using cmake system or
its files easily.

Then we can also think whether we want to compile BT under Windows as
soon as possible, or to have a stable Qt-only release before that. If
we want to move to Windows sooner, we can move to other KDE->Qt
changes even before the htmlreaddisplay is completed.

Personally I feel that heading for Windows would give an extra
motivation. The downside is that if it creates new problems the
Qt-only stable release will be deferred in all platforms.

> At my work we have used branches. They do cause some extra work to
> merge the branch and trunk. We would prefer to keep the HEAD stable and
> make a new release from the HEAD. We do use branches, but only to do
> bug fixing of a previous release, not to add new features.

I believe that's one reason why a distributed vcs is much better -
it's easy to do merges. Another reason is that it makes experimental
development easier because it's easy to create and delete branches and
change individual commits or commit sets between them. But that's
another story - we use SVN now and have to live with it.


--Eeli Kaikkonen