On Monday 29 November 2010 17:09:35 Matthias Fuchs wrote:
> Am Montag 29 November 2010, 17:57:45 schrieb Fredrik Höglund:
> > I'm pretty sure Aaron meant annotate when he said bisect.
>
> Yes that would indeed be a problem.
> I have no clue if there would be a way around this without inflicting mo
Am Montag 29 November 2010, 17:57:45 schrieb Fredrik Höglund:
> On Monday 29 November 2010, Matthias Fuchs wrote:
> > Am Sonntag 28 November 2010, 22:48:56 schrieb Aaron J. Seigo:
> > > so yes, a reformat will create an "opaque membrane" in the history of
> > > the repository, but wether that is ac
Am Sonntag 28 November 2010, 22:48:56 schrieb Aaron J. Seigo:
> 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
> mont
Am Sonntag 28 November 2010, 22:48:56 schrieb Aaron J. Seigo:
> 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
> mont
On Sunday, November 28, 2010, Martin Gräßlin wrote:
> 1. Follow the rules from Plasma concerning coding style (and all other
> development matters - reviews, git, mergin...)
i forgot to make this explicit in my earlier email, but it's worth saying imo:
to me this means that when we make decisions
Hummm... but /I/ _really_ *like* the style as it is now!!!
...
As for the transition, i guess it mostly depends on automated fixing
reliability (i ran that once in kdevelop years ago and _never_ tried it again,
but i guess the tools have meanwhile improved ;-)
Otherwise (ie if automated conve
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 _ne
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 i
On Sunday 28 November 2010 21:18:55 Chani wrote:
> a new branch? two weeks? why?
> isn't there a program for reformatting code, that could just sweep over all
> of it and be one commit? even if it's not perfect, something that could at
> least fix the brace indentation...
let's say I don't trust it
Just noting that plasma coding style is the same as kdelibs [1]
--
Cheerio,
Ivan
[1] http://techbase.kde.org/Policies/Kdelibs_Coding_Style
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
__
Hi,
CC-int Plasma as I would like to get some opinion on it.
From various discussion on IRC and looking through review requests, it seems
that we have a general problem with our coding style.
* The coding style is only used in KWin
* Developers seem to have problems with it, nobody really know
11 matches
Mail list logo
