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
signature.asc
Description: This is a digitally signed message part.
