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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
