KDE git workflow

[Aaron J. Seigo]

On Thursday, June 9, 2011 13:50:59 David Jarvie wrote:
> One side effect of using integration branches in what used to be
> kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely
> tested until later in the development cycle than previously. 

features should not remain in integration branches for overly long. if they 
are of such low quality that even in integration problems arise, then there is 
little reason to inflict them on a wider audience. at the same time, 
integration must not become a place where new code piles up and piles up until 
a release nears, leading to code drops into master at odd intervals.

this means that there is some discipline required by those who tend the 
integration branches.

> While they
> are in integration branches, only people who are particularly interested
> in those areas are likely to use them, and it's only once they eventually
> reach master that they will be widely used by developers. 

which is actually good. once a feature is deemed stable enough by those of us 
who stay on the truly bleeding edge, they can fall into master. this means 
master should be much more reliable and we can realistically get more people 
running straight from master without it doing nasty things to their system.

iow, by having a reservoir where new things land before they spill over into 
master, we can get more people using master and therefore ultimately more 
people testing things.

we've noticed in plasma development, whether it is in libs, runtime or 
workspace, that new features often land with obvious shortcomings (though 
often not obvious to the original developer) which the core team quickly take 
care of. at that point the feature is ready for broader testing, and before 
that it's a waste of everyone's time and trust. because they enter prematurely 
into master, we limit the number of people willing to run master, and for good 
reason.

> In one way,
> that's a good thing, since there should be less bugs encountered by those
> not directly involved. 

exactly..

> But the overall effect could be to slow down bug fixing of new features.

not if there is a reasonable flow from feature branch -> integration -> master 
and not if we increase the # of people who also run master.

right now, we get too many reports only after betas start rolling, when all 
sorts of features have landed over the course of a couple of months, and right 
now there is little way for the core team to test feature branches without 
harming master.

as Cornelius mentioned, we discussed this at the Platform 11 meeting as it is 
something we were also concerned about. imho as long as we are aware of why we 
are doing this and what we need to avoid doing in the process, we'll be ok :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110610/22fcbf92/attachment.sig>