KDE git workflow

[Cornelius Schumacher]

On Thursday 09 June 2011 Maksim Orlovich wrote:
> 
> Will we have a single person review every single commit to master, too?

We don't have formal rules about who reviews commits. That will be done by the 
developers and maintainers who care, just like it is done now.

> > We might have a "Aaron's branch" of Plasma with
> > the latest Plasma features, or a "KDAB branch" of KDE PIM, which
> > integrates the latest KDE PIM enterprise features, etc.
> 
> And what if there are multiple branches on the same module at the same
> time? Which one of these branches, or master (or release?) is going to
> get testing coverage?

The idea is that, if there are multiple feature branches, the integration 
branch is used to collect them and get testing coverage and review there.

> An alternative, of course, is to discourage use of branches if at all
> possible, and rather
> prefer a consistently working and stable master (which optionally then
> becomes the release, without further branching)... or at the very
> least not to disallow such methodology by fiat.

For smaller or less central parts of KDE this actually might be a good 
procedure. For modules where many developers work, or where we need to make 
extra sure that they are work, like the libraries, we need more review.

And discouraging branches at all is not a good policy, as at least there 
should be local branches for development of everything, which is non-trivial 
to integrate, otherwise a consistently working and stable master is impossible 
to achieve.

The same for releasing. We need branches for that, so that master can continue 
to get feature development, while a branch is hardened for release.

-- 
Cornelius Schumacher <schumacher at kde.org>