On Sunday, November 28, 2010, Christoph Feck wrote: > On Sunday 28 November 2010 20:20:33 Martin Gräßlin wrote: > > From various discussion on IRC and looking through review requests, it > > seems that we have a general problem with our coding style. > > For kdelibs, we have a policy that only _new_ code needs to follow the > style guidelines. Existing code is not reformatted. I would prefer > switching to kdelibs style in kwin, but only for new code (i.e. new files > or new functions).
kwin and kdelibs differ in some ways that are significant to this: * kwin has just undergone a maintainership change and has "a" maintainer; kdelibs is maintained in pieces by a relatively large number of people and there is long term continuity of that maintainership * kdelibs is developed in pieces (e.g. this class or that group of classes) rather than as a holistic whole, which kwin is; this means that kdelibs hacking is less affected by global consistency than kwin is. so yes, a reformat will create an "opaque membrane" in the history of the repository, but wether that is actually a problem or not comes down to the development practices around kwin. e.g. how important is it to git bisect N months in the past? ballance this (and how often the history is really used in this manner in kwin) with the benefits of code clarity in terms of keeping bar for contribution low and quality high. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
