[Kde-pim] Re: Opening kdepim master for feature commits, branching kdepim 4.6

[John Layt]

On Friday 22 Apr 2011 14:29:03 Torgny Nyblom wrote:
> On Friday 22 April 2011 12.22.48 Christophe Giboudeaux wrote:

> > Before reopening kdepim, I believe we should answer Kevin's question
> > about the commit strategy/policy in kdepim: develop in master &
> > cherry-pick in branch (svn style) or develop new features in staging
> > branches and merge them into master when new features become mature
> > (kernel style)
> 
> 1 vote for kernel style, ie master should always be in a releaseable state

Frankly, given that is the way git was designed to work that decision was made 
when KDE chose git for its feature branch support.  Development should never 
take place in master.  All development and bug-fixes should be taking place in 
branches, either local for small changes or centrally on git.kde.org for major 
features or collaborative development.

The real question is how do we decide when a branch is ready to be merged into 
master, and that's where the kernel model comes in.  The obvious rules apply, 
such as must compile, must pass unit tests, but does it need to be 100% 
feature complete, or is there some slack?  Each project will need to decide 
what rules to apply itself and whether they will have some formal staging area 
or sign-off process, although it's about time for kdelibs to decide a policy 
to set a standard.

Given that the Hard Feature Freeze immediately preceeds the release of Beta 1, 
and any new features will need to be in master by then to be included in the 
beta release, the definition of "ready to merge" is likely to become "ready 
for a beta 1 release".

John.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/