policy change related to kdelibs snapshots

[Dirk Mueller]

On Monday 10 July 2006 18:31, Stephan Kulow wrote:

> Yes, but that doesn't mean it can't happen in a parallel branch, which is
> then merged in bigger chunks to limit the times you have to recompile to
> get an uptodate trunk.

well, do we merge bleeding then more often that once every two weeks? So apps 
developers do have to recompile on a frequent basis? Then it makes even less 
sense to me. 

Anyway, as I'm insulted on IRC that I'm too stupid to get it and that I'm not 
a kdelibs developer anyway. let me just repeat my thoughts on why I tend to 
disagree on the proposal.

a) if you want to to simple source incompatible changes (class KFoo -> 
KFooBar), you don't need a separate branch for that. you just need a 
compiling checking, do your change, and fix up compilation, and commit. Doing 
so in bleeding-edge is probably going to hurt, as bleeding-edge is not 
guaranteed to compile due to bigger changes being just developed by 
the "real" kdelibs developers. if you can't compile, you commit incomplete 
changes, and break it for all the other bleeding developers. A full bleeding 
tree makes this actually a lot more difficult, not easier. It also makes a 
lot more work for whoever works on the bleeding branch. 

b) bigger changes shouldn't be done in bleeding edge branch, because it takes 
long for them to finish, and while they're not finished, the bleeding 
branches can't be merged onto trunk. This leads to the discussion on IRC that 
changes need to be backed out from the bleeding branches in order to get one 
change finished and be merged back to trunk. frequently, errors happen and 
unfinished stuff gets merged to trunk, breaking the compile or generally , 
being a bad or unfinished idea, which leads to hectic porting work and 
confused app developers. 

Therefore, as I suggested, it would be better to make simple changes always in 
trunk. source incompatible changes that require recompile everything will be 
scheduled on a special day, like the usual BIC friday we always had. Other 
nontrivial stuff has to be done on a branch. 

This has the following advantages: 

a) one finished refactoring can be merged independently if something else is 
finished. we don't have to wait for n different things going on to be 
finished before changes can be merged easily again. Right now we have the 
situation that a new snapshot can't be made because not everything has been 
ported, and because new changes have been done in kdelibs which break even 
more. 

b) changes on bleeding branches don't drip over each others foot. one thing 
can be done at a time, and it actually gives kde-core-devel a chance to do 
API review or general "does this make sense?" review easily (for example the 
KSystemTray change). a simple bleeding branch makes API review and regression 
test very hard (was this breakage due to my change or due to some other 
change that just happened to happen at the same time in bleeding branch?)

c) it doesn't require libs developers to have two complete checkouts compiled 
and updated. for those who don't have a 150 nodes icecream cluster, this 
probably makes a difference. 

d) application developers are not confused as to which branch they should 
compile against (its all trunk)

e) simple bugfixes don't need to be committed to kdelibs and to 
kdelibs4_snapshot. its all trunk. 

f) application developers can just stop updating kdelibs when they develop 
something. when they're finished with testing, they commit. resolving 
conflicts on commit should be easy as by definition trunk is only allowed to 
be changed in trivial ways within merges. full recompiles are limited to BIC 
fridays. 

g) refactoring developers "own" the branch, and they're isolated from whatever 
other thunder is going on. if you only have 2 hours per day for your 
refactoring, you don't want to hunt behind everyone else. 

h) its the way it has always been before, and it used to work. we didn't 
change that much that we now need bleeding and branches above or below 
bleeding branches. 

Most of all, it gives some control back and some development style, because 
branches can be considered individually for merge. It also only requires one 
checkout for both the one doing a certain big change and the one who doesn't. 

Also, no SVN history is lost due to frequent re-snapshotting. 


Dirk