[Kde-scm-interest] Git roadmap

[Johannes Sixt]

Thiago Macieira schrieb:
> Johannes Sixt wrote:
>> You can also view the public repositories as playground. Let everyone
>> and his dog push to them, and the "lieutenants" pick the cherries from
>> there.
> 
> Agreed. The public/free for all repositories will have an enormous amount 
> of branches.
> 
> But I am not sure it fits exactly our culture if we restrict each person 
> to his own branches.

I do understand that this culture (every change is immediately visible to 
others) is an advantage if we are looking at bug fixes that are committed by 
people who know what they do.

But let's look at a different soft of changes, like API adaptations that 
require cross-module changes. Today, any enthusiast is able to change an API 
somewhere in kdelibs and probably make corresponding adaptations in his 
favorite module, but forget about other modules. If our enthusiast does not 
cooperate *right away*, someone else has to step in an fight the fire, 
*right away* otherwise many other developers suffer.

Or look at these commit messages of the kind "Fix foo." (Huh? What was the 
problem?) and in the next revision "Gaah - forgot to add these files", and 
the next one "Remove accidentally committed debugging printfs". Isn't this 
disgusting?

Here I must admit that IMHO this culture needs a change to the better, and 
git is the tool that allows that change. Since cherry-picking and selective 
merging of branches is so easy with git, it's only a small step to enforce 
peer review.

> Taking a concrete example: dashbot reported a few days ago that 
> extragear/libs/libksane wasn't compiling because it was using 
> variable-length arrays. I thought it was an easy fix, so I went ahead and 
> replaced all uses with QVarLengthArray. Then I pushed my fixes (git svn 
> dcommit, actually).
> 
> If I were confined to a branch called thiago/something, dashbot would not 
> see my fix and would keep on complaining until the libksane maintainer 
> merged my fixes. Thankfully he's active, but what if he had just gone on 
> vacations for two weeks? Should I wait three days and then escalate to 
> the extragear-libs maintainer?

That's an excellent example, thank you!

Why do you think that dashbot would not see your changes? You would have 
published them in the public repository anyway. I'd even go as far as to say 
that *before* you ask the libksane maintainer to pull your fix, you ask 
dashbot to pull them and act as the peer reviewer.

That's the whole point of git: It doesn't matter whether the changes 
originate from your private area or from the official repository - it's 
identical.

> That's why I think everyone should have access to "master" on the public 
> repository and other "public" branches.

And I just illustrated a workflow that doesn't make this necessary, and that 
will even increase the overall quality of the code base: because you can 
have peer review easily and early and push only acknowledged changes upstream.

-- Hannes