[bt-devel] QtWebKit DOM access

[Eeli Kaikkonen]

Martin Gruner wrote:
> 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.
>

Anyways, I meant that someone has to keep two different codebases for a 
while if webkit is kept apart. #ifdefs help with that, of course, so 
that all can be in one codebase. But usually branches are used for large 
scale parallel development, not #ifdefs.

>> 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.

I have to admit I don't necessarily understand you completely here. If 
webkit brings in much work, uncertainty and potential bugs, as it 
certainly will, we can't release it for a while. And yet after releasing 
1.7 we should be able to react immediately if we find a crash or someone 
can't build the source. Otherwise users/packagers are left with 
essentially beta quality software. Of course the first release can be 
1.7.0 and those bugfix releases can be 1.7.0.1 and so on, and the next 
feature release can be 1.7.1. But then we should branch 1.7.0 and the 
HEAD is for 1.7 development. Again, #ifdefs could make branching 
unnecessary, but who can say that khtml and webkit will be so compatible 
that it doesn't create problems and extra work? And when the webkit 
would be working we would have to change and remove big amount of code.

Basically I'm still open to any path, but I would like to hear why 
exactly you are against branching, if that was your point.


--Eeli Kaikkonen