[bt-devel] QtWebKit DOM access

[Martin Gruner]

Hi Eeli,

> I'm not a version control system expert so I can't defend branching. But
> with logical thinking I come to conclusion that if someone has a private
> branch home it has almost the same problems. Gary should update his
> private codebase with all public updates so that he can merge back
> easily. (I highly recommend git with git-svn for that. I use it with
> several private branches which I keep in sync with the SVN HEAD and from
> which I commit to the SVN HEAD.)

Here you are not talking about real branches, but checkouts. A branch starts 
from a certain point but then moves into a different direction than HEAD (I'm 
no expert either) - just like you suggest for a 1.7 branch. A branch will also 
be checked in, but not to HEAD, but to the branch itself.

> "Requires significant effort to keep things in sync" - this would not be
> a great problem with a distributed vcs, they are created for easy
> branching/merging and easy changing of patchsets etc. But I don't see
> why this would be a great problem even with SVN. If the 1.7 branch would
> get only small/important bugfixes + bookself manager fixes keeping it in
> sync shouldn't be hard. We could put all KDE->Qt changes to the webkit
> based HEAD only.
>
> I see also another reason for 1.7 branch: if we release 1.7 in HEAD and
> then change the code radically it will take much time before we can
> release a new stable version. There will surely be bugs in 1.7 which
> need immediate fixing (crashes and build problems) because we don't have
> enough testers now. Those fixes would be easy to put into 1.7 branch and
> then release 1.7.1 etc. if needed.

I would like to follow a different path. Subsequent releses which do not only 
fix bugs, but also introduce new features, in the 1.7 series. Otherwise we'll 
fail to achieve the "release early, release often" principle again.
Working in HEAD would require discipline to only make changes which keep HEAD 
in a releaseable state (not at every point, but most of the time). We 
shouldn't make too "radical" changes - and they are not needed, as Gary 
outlined.

mg