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

[Michael Pyne]

On Monday 19 January 2009, Johannes Sixt wrote:
> Ian Monroe schrieb:
> > On Sat, Jan 17, 2009 at 5:17 PM, Thiago Macieira <thiago at kde.org> wrote:
> >>  * should we use a patch-submission-and-review system? (probably not)
> >
> > no.
>
> Don't throw patch submission and review into the same bucket. I can
> understand that you want to dispense with patch submission. But if KDE had
> a good culture of *review* from the beginning, there wouldn't be so many
> crap commits in the SVN.

Not every KDE project has gobs and gobs of developers with which to do review. 
=D

> A network of trust with a hierarchy of maintainers would foster the review
> culture.

Well a hierarchy type architecture appeals very much to the Naval Officer in 
me.  However having lived in a hierarchical scheme I can also tell you that it 
breaks down if a higher-up in the chain is not available (what we do in the 
Navy is have approximately eightly hojillion different methods of reaching 
higher ups, we have standing orders, etc. etc.  Good luck duplicating that in 
KDE ;).

Do you bypass the guy who reviews your patches and instead submit it to the 
next higher guy? (Hint: NO, unless you've already cleared such behavior)

What happens if someone in the chain becomes unavailable due to other more 
important committments (after all, the propotion of paid KDE devs is much 
lower than for the Linux kernel)?

Who is responsible for what?  And how do we decide?  (i.e. is there a 
qualification process for moving up the hierarchy, or is it based on a vote, 
or what?)

Note that svn doesn't prevent us from enforcing more access control on the 
different repositories, but instead we choose not to.

So what prevents (or minimizes) people committing all willy-nilly?  The social 
expectation that it is poor form to just drop commits in the middle of 
someone's code (at least without a CCMAIL).  And after-the-fact code review of 
various changes.  In addition the various KDE mailing lists are used to review 
patches before they are committed (i.e. for stuff like kdelibs or 'this fixes 
foo in kbar but I can't reach the maintainer, should I commit?')

So while a hierarchical chain may work well for projects like Amarok I don't 
think it would work in general for KDE (and I think it trades us a different 
set of problems to solve ones which I at least consider minor).

Regards,
 - Michael Pyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090119/a0b8012b/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090119/a0b8012b/attachment.sig