[Kde-scm-interest] On Amarok Switching to Git

[Johannes Sixt]

Thiago Macieira schrieb:
> Johannes Sixt wrote:
>> Thiago Macieira schrieb:
>>> Ian Monroe wrote:
>>>>>  * the unresolved issue of accountability
>>>> This is the main issue I see. I hear there are solutions though?
>>> We have to see whether Git notes solves the problem.
>> I still don't see a need for this. Just build a network of trust (or
>> better, make use of it - because it already exists), with only one or
>> two people who can push into "the repository" (that you named
>> mainline.git), with their trusted lieutenants, etc, then accountability
>> is no problem - you'll always know who pushed the commits. This should
>> work particularly well with Amarok.
> 
> That won't work in KDE.
> 
> Very simple scenario: I build Amarok with Qt 4.5 and fixe an issue there. 
> I would like to simply push to the repository, like I do with any other 
> part of KDE. If I have to send a patch to someone (who may be away or may 
> forget to apply it), I'll be less likely to make the modification.

Has your change been reviewed? No. You just modified Amarok without
consulting the ones who know it in and out. I'm aware that you know a lot
about the codebase, and you are a core person as core can be, but
by-passing the maintainers of a piece of software that you don't maintain
yourself is a bit... hm... patronizing, isn't it? It's precisely the
reason why so many crappy commits happened in the past.

Even *you* should be forced to play by the rules. You can still stick the
commit into your own public repo and ask the maintainers to pull it when
they feel the time is right to do so.

Continuing your simple scenario: Your fix is not just needed for Qt 4.5,
but is perhaps more serious, and needs to be "backported" to earlier
Amarok versions. The maintainers can decide to apply the fix to the
earlier version(s) and merge it forward. *You* wouldn't have done that,
would you?

> Even if for Amarok we can have a temporary solution, this won't work for 
> other KDE modules. Who will be allowed to push to kdelibs or kdebase? Who 
> will make the decision on who those people will be? And how does one get 
> added to this "special developers" group?

This all happens by earning "trust points". For example, if you were the
only one who pushes to kdelibs, I would not hesitate a second to download
your kdelibs repository, and accept it as "the" kdelibs.

If there were a vote in the KDE community who should be "the one", then I
expect that 99% of the votes will be shared by at most 10 people. 9 of
them I expect to decline because the task and responsibilty is heroic.

> It's not a technical problem, it's a social one.

Trust *is* social. But it leads to much better code quality than "all
people are equal".

-- Hannes