Anthony Liguori writes:
> On 08/22/2010 01:36 PM, malc wrote:
>
> But how would you do that? Drop the CODING_STYLE (and accept
> anything)? Switch to a new CODING_STYLE that is widely appreciated and
> so all bikeshedding will cease? Enforce current style?
>
I w
Jes Sorensen wrote:
> On 08/22/10 20:35, malc wrote:
>> On Sun, 22 Aug 2010, Blue Swirl wrote:
>>> What's the ultimate editor? I'd love to drop Emacs, which is annoying
>>> but does its job better than the others that I've tried.
>>>
>> ed
>
> ed is for sissies, real developers use cat, echo
Jes Sorensen wrote:
> On 08/22/10 20:39, malc wrote:
>
>> Disregarding my own stance on the braces, braces around single statement
>> is actually helpful w.r.t. debugging imaging trying to set a break point
>> on said singlesttement, plain impossible in following case:
>>
>> if (a) b;
>>
>
On 08/23/2010 05:07 PM, Jes Sorensen wrote:
On 08/23/10 16:03, Avi Kivity wrote:
On 08/23/2010 04:55 PM, Jes Sorensen wrote:
Well with the inconsistency we have now, what is the right iron fist to
apply? Demand the code is consistent with the file you edit or that it's
consistent with whats
On 08/23/10 16:03, Avi Kivity wrote:
> On 08/23/2010 04:55 PM, Jes Sorensen wrote:
>>
>> Well with the inconsistency we have now, what is the right iron fist to
>> apply? Demand the code is consistent with the file you edit or that it's
>> consistent with whats in CODING_STYLE, even if it means th
On 08/23/2010 04:55 PM, Jes Sorensen wrote:
Well with the inconsistency we have now, what is the right iron fist to
apply? Demand the code is consistent with the file you edit or that it's
consistent with whats in CODING_STYLE, even if it means that what you
apply is completely different to the
On 08/22/10 22:39, Avi Kivity wrote:
> On 08/22/2010 10:44 PM, malc wrote:
>>
>>> There is the problem that some patch submitters are reminded of
>>> CODING_STYLE while others aren't. Some don't need to be reminded but
>>> they are not part of the problem.
>> And to this i fully subscribe.
>
> I
On 08/22/10 20:42, Anthony Liguori wrote:
> On 08/22/2010 01:36 PM, malc wrote:
>
> But how would you do that? Drop the CODING_STYLE (and accept
> anything)? Switch to a new CODING_STYLE that is widely appreciated and
> so all bikeshedding will cease? Enforce current style?
>
On 08/23/2010 02:01 PM, Markus Armbruster wrote:
Avi Kivity writes:
On 08/22/2010 07:40 PM, Jes Sorensen wrote:
I totally agree with Markus
that it seems like wasted effort to come up with new tools and having to
maintain them when there are good ones out there like the ones from the
Linux
Avi Kivity writes:
> On 08/22/2010 07:40 PM, Jes Sorensen wrote:
>> I totally agree with Markus
>> that it seems like wasted effort to come up with new tools and having to
>> maintain them when there are good ones out there like the ones from the
>> Linux kernel.
>>
>
> scripts/Lindent is just a
Am 22.08.2010 20:42, schrieb Anthony Liguori:
> On 08/22/2010 01:36 PM, malc wrote:
>
> But how would you do that? Drop the CODING_STYLE (and accept
> anything)? Switch to a new CODING_STYLE that is widely appreciated and
> so all bikeshedding will cease? Enforce current style?
On 08/22/10 20:39, malc wrote:
> Disregarding my own stance on the braces, braces around single statement
> is actually helpful w.r.t. debugging imaging trying to set a break point
> on said singlesttement, plain impossible in following case:
>
> if (a) b;
Oh there is no talk about suggesting we
On 08/22/10 20:13, Blue Swirl wrote:
> Well, consider for example mass braces conversion to the One Style,
> whichever that is. Would it be better to do it in one commit or
> multiple commits? If the latter, push all commits back-to-back or just
> one at a time now and then?
>
> At the extreme end
On 08/22/10 20:35, malc wrote:
> On Sun, 22 Aug 2010, Blue Swirl wrote:
>> What's the ultimate editor? I'd love to drop Emacs, which is annoying
>> but does its job better than the others that I've tried.
>>
>
> ed
ed is for sissies, real developers use cat, echo, and sed.
Jes
On Sun, Aug 22, 2010 at 8:12 PM, Avi Kivity wrote:
> On 08/22/2010 07:40 PM, Jes Sorensen wrote:
>>
>> I totally agree with Markus
>> that it seems like wasted effort to come up with new tools and having to
>> maintain them when there are good ones out there like the ones from the
>> Linux kernel
On 08/22/2010 10:44 PM, malc wrote:
There is the problem that some patch submitters are reminded of
CODING_STYLE while others aren't. Some don't need to be reminded but
they are not part of the problem.
And to this i fully subscribe.
I agree.
From my Linux experience, I started out whining
On Sun, 22 Aug 2010, Blue Swirl wrote:
> On Sun, Aug 22, 2010 at 7:44 PM, malc wrote:
> > On Sun, 22 Aug 2010, Anthony Liguori wrote:
> >
> >> On 08/22/2010 01:56 PM, Blue Swirl wrote:
> >> > > Why is this even still being discussed? What problem are people
> >> > > actually
> >> > > trying to
On 08/22/2010 03:09 PM, Avi Kivity wrote:
On 08/22/2010 09:56 PM, Blue Swirl wrote:
Can someone point to a bug in QEMU that's been caused because of
CODING_STYLE or the fact that some patches don't adhere to it?
7b1df88f284f462ecb236931ad863a815f243195
How was this bug caused by CODING_STY
On Sun, 22 Aug 2010, Anthony Liguori wrote:
> On 08/22/2010 01:56 PM, Blue Swirl wrote:
> > > Why is this even still being discussed? What problem are people actually
> > > trying to solve?
> > >
> > > Can someone point to a bug in QEMU that's been caused because of
> > > CODING_STYLE or the fac
On 08/22/2010 11:17 PM, Anthony Liguori wrote:
On 08/22/2010 03:09 PM, Avi Kivity wrote:
On 08/22/2010 09:56 PM, Blue Swirl wrote:
Can someone point to a bug in QEMU that's been caused because of
CODING_STYLE or the fact that some patches don't adhere to it?
7b1df88f284f462ecb236931ad863a8
On 08/22/2010 11:20 PM, Jes Sorensen wrote:
I happen to like the single line braces rule. That is, I don't like how
the code looks (I dislike punctuation generally), but I like the
consistency and I like how patches that add or remove a line are easy to
read.
My preference would be: new code
On 08/22/2010 11:16 PM, Blue Swirl wrote:
scripts/Lindent is just a wrapper around indent(1). We don't need to come
up with new tools, just come up with the right switches to indent(1).
More importantly, we want checkpatch.pl.
That's a bit too obnoxious in my opinion. I think the main thi
On 08/22/10 22:15, Avi Kivity wrote:
> On 08/19/2010 09:29 PM, Blue Swirl wrote:
>>
>>> Just to be sure I follow, are you suggesting we relax all of the bracing
>>> rule, or just the part about braces around single line statements? I'd
>>> be happy to write up a patch for the latter.
>> I'd rather
On Sun, Aug 22, 2010 at 8:09 PM, Avi Kivity wrote:
> On 08/22/2010 09:56 PM, Blue Swirl wrote:
>>
>>> Can someone point to a bug in QEMU that's been caused because of
>>> CODING_STYLE or the fact that some patches don't adhere to it?
>>
>> 7b1df88f284f462ecb236931ad863a815f243195
>
> How was this
On 08/19/2010 09:29 PM, Blue Swirl wrote:
Just to be sure I follow, are you suggesting we relax all of the bracing
rule, or just the part about braces around single line statements? I'd
be happy to write up a patch for the latter.
I'd rather not relax the rules but find a solution so that the
On 08/22/2010 07:40 PM, Jes Sorensen wrote:
I totally agree with Markus
that it seems like wasted effort to come up with new tools and having to
maintain them when there are good ones out there like the ones from the
Linux kernel.
scripts/Lindent is just a wrapper around indent(1). We don't
On 08/22/2010 09:56 PM, Blue Swirl wrote:
Can someone point to a bug in QEMU that's been caused because of
CODING_STYLE or the fact that some patches don't adhere to it?
7b1df88f284f462ecb236931ad863a815f243195
How was this bug caused by CODING_STYLE? In fact, if CODING_STYLE was
applied
On 08/22/2010 09:42 PM, Anthony Liguori wrote:
I'm strongly opposed to any reformatting of the tree.
I strongly second this statement.
All it does is break git blame which makes debugging harder without
offering any real benefits.
Even worse, it makes backporting patches much harder.
On Sun, Aug 22, 2010 at 7:28 PM, Anthony Liguori wrote:
> On 08/22/2010 01:56 PM, Blue Swirl wrote:
>>>
>>> Why is this even still being discussed? What problem are people actually
>>> trying to solve?
>>>
>>> Can someone point to a bug in QEMU that's been caused because of
>>> CODING_STYLE or th
On Sun, Aug 22, 2010 at 7:44 PM, malc wrote:
> On Sun, 22 Aug 2010, Anthony Liguori wrote:
>
>> On 08/22/2010 01:56 PM, Blue Swirl wrote:
>> > > Why is this even still being discussed? What problem are people actually
>> > > trying to solve?
>> > >
>> > > Can someone point to a bug in QEMU that's
On 08/22/2010 01:56 PM, Blue Swirl wrote:
Why is this even still being discussed? What problem are people actually
trying to solve?
Can someone point to a bug in QEMU that's been caused because of
CODING_STYLE or the fact that some patches don't adhere to it?
7b1df88f284f462ecb236931ad86
On Sun, Aug 22, 2010 at 6:41 PM, Anthony Liguori wrote:
> On 08/22/2010 11:49 AM, Jes Sorensen wrote:
While wasting time for historical reasons is certainly better than
wasting time for the heck of it, it's arguably worse than stopping the
waste.
>>>
>>> But how would you
On 08/22/2010 01:36 PM, malc wrote:
But how would you do that? Drop the CODING_STYLE (and accept
anything)? Switch to a new CODING_STYLE that is widely appreciated and
so all bikeshedding will cease? Enforce current style?
I would suggest we either clean up the existing rule, or switc
On 08/22/2010 11:49 AM, Jes Sorensen wrote:
While wasting time for historical reasons is certainly better than
wasting time for the heck of it, it's arguably worse than stopping the
waste.
But how would you do that? Drop the CODING_STYLE (and accept
anything)? Switch to a new CODING_STYL
On Sun, 22 Aug 2010, Blue Swirl wrote:
> On Sun, Aug 22, 2010 at 4:40 PM, Jes Sorensen wrote:
> > On 08/21/10 12:47, Blue Swirl wrote:
> >> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster
> >> wrote:
> >>> Unless you mass-convert existing code to your style, tools working on
> >>> source fil
On Sun, 22 Aug 2010, Blue Swirl wrote:
> On Sun, Aug 22, 2010 at 4:49 PM, Jes Sorensen wrote:
> > On 08/21/10 16:03, Blue Swirl wrote:
> >> On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster
> >> wrote:
> >>> Could be "fun" for developers using Windows. If they exist.
> >>
> >> At least OCaml
On Sun, 22 Aug 2010, Blue Swirl wrote:
> On Sun, Aug 22, 2010 at 5:00 PM, malc wrote:
> > On Sun, 22 Aug 2010, Jes Sorensen wrote:
> >
> >> On 08/21/10 16:03, Blue Swirl wrote:
> >> > On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster
> >> > wrote:
> >> >> Could be "fun" for developers using W
On Sun, Aug 22, 2010 at 5:00 PM, malc wrote:
> On Sun, 22 Aug 2010, Jes Sorensen wrote:
>
>> On 08/21/10 16:03, Blue Swirl wrote:
>> > On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster
>> > wrote:
>> >> Could be "fun" for developers using Windows. If they exist.
>> >
>> > At least OCaml site
On Sun, Aug 22, 2010 at 4:49 PM, Jes Sorensen wrote:
> On 08/21/10 16:03, Blue Swirl wrote:
>> On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster
>> wrote:
>>> Could be "fun" for developers using Windows. If they exist.
>>
>> At least OCaml site offers binary download for Windows. I didn't
>>
On Sun, Aug 22, 2010 at 4:40 PM, Jes Sorensen wrote:
> On 08/21/10 12:47, Blue Swirl wrote:
>> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote:
>>> Unless you mass-convert existing code to your style, tools working on
>>> source files won't cut it, because reports of the patch's style
>>
On Sun, 22 Aug 2010, Jes Sorensen wrote:
> On 08/21/10 16:03, Blue Swirl wrote:
> > On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster
> > wrote:
> >> Could be "fun" for developers using Windows. If they exist.
> >
> > At least OCaml site offers binary download for Windows. I didn't
> > compi
On 08/21/10 16:03, Blue Swirl wrote:
> On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster wrote:
>> Could be "fun" for developers using Windows. If they exist.
>
> At least OCaml site offers binary download for Windows. I didn't
> compile Coccinelle myself, so I don't know how much that helps.
On 08/21/10 12:47, Blue Swirl wrote:
> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote:
>> Unless you mass-convert existing code to your style, tools working on
>> source files won't cut it, because reports of the patch's style
>> violations are prone to drown in a sea of reports of preex
On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster wrote:
> Blue Swirl writes:
>
>> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote:
>>> Blue Swirl writes:
>>>
On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster
> wro
Blue Swirl writes:
> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote:
>> Blue Swirl writes:
>>
>>> On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster
wrote:
> Anthony Liguori writes:
>> To be perfectly honest, we
On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote:
> Blue Swirl writes:
>
>> On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
>>> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster
>>> wrote:
Anthony Liguori writes:
> To be perfectly honest, we have enough hard problems to s
Blue Swirl writes:
> On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
>> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster wrote:
>>> Anthony Liguori writes:
To be perfectly honest, we have enough hard problems to solve in QEMU.
We're spending a lot more time on coding style than
On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
On 08/13/10 20:02, Blue Swirl wrote:
> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Fil
On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster wrote:
> Anthony Liguori writes:
>
>> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>>> On 08/13/10 20:02, Blue Swirl wrote:
>>>
On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
wrote:
> The existing code that I have to
Anthony Liguori writes:
> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>> On 08/13/10 20:02, Blue Swirl wrote:
>>
>>> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
>>> wrote:
>>>
The existing code that I have touched don't follow the current coding
style guidance,
On Thu, Aug 19, 2010 at 1:32 PM, Jes Sorensen wrote:
> On 08/17/10 20:56, Blue Swirl wrote:
>> On Tue, Aug 17, 2010 at 1:55 PM, Jes Sorensen
>> wrote:
>>> I think we are in full agreement here, I am really just worried that we
>>> add additional procedures here that will slow down the real devel
On 08/17/10 20:56, Blue Swirl wrote:
> On Tue, Aug 17, 2010 at 1:55 PM, Jes Sorensen wrote:
>> I think we are in full agreement here, I am really just worried that we
>> add additional procedures here that will slow down the real development.
>
> Either the braces rule in CODING_STYLE is downgrad
On Tue, Aug 17, 2010 at 1:55 PM, Jes Sorensen wrote:
> On 08/17/10 15:21, Anthony Liguori wrote:
>> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>>> On 08/13/10 20:02, Blue Swirl wrote:
I fully agree on the need of change and support your excellent idea.
There are other ways to solve the
On Tue, Aug 17, 2010 at 8:04 AM, Jes Sorensen wrote:
> On 08/13/10 20:02, Blue Swirl wrote:
>> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
>> wrote:
>>> The existing code that I have touched don't follow the current coding
>>> style guidance, much less all the new recommendations bei
On 08/17/10 15:21, Anthony Liguori wrote:
> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>> On 08/13/10 20:02, Blue Swirl wrote:
>>> I fully agree on the need of change and support your excellent idea.
>>> There are other ways to solve the problem, but I believe we need more
>>> order than mor
On 08/17/2010 03:04 AM, Jes Sorensen wrote:
On 08/13/10 20:02, Blue Swirl wrote:
On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
wrote:
The existing code that I have touched don't follow the current coding
style guidance, much less all the new recommendations being suggeste
On 08/13/10 20:02, Blue Swirl wrote:
> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
> wrote:
>> The existing code that I have touched don't follow the current coding
>> style guidance, much less all the new recommendations being suggested.
>>
>> Although, I do believe that this situati
On Fri, 13 Aug 2010, Blue Swirl wrote:
> On Thu, Aug 12, 2010 at 6:56 PM, malc wrote:
> > On Thu, 12 Aug 2010, Blue Swirl wrote:
> >
> >> Add a few rules, based loosely on libvirt HACKING.
> >>
> >> Blue Swirl (5):
> >> CODING_STYLE: add preprocessor rules
> >> CODING_STYLE: add C type rules
On Thu, Aug 12, 2010 at 6:56 PM, malc wrote:
> On Thu, 12 Aug 2010, Blue Swirl wrote:
>
>> Add a few rules, based loosely on libvirt HACKING.
>>
>> Blue Swirl (5):
>> CODING_STYLE: add preprocessor rules
>> CODING_STYLE: add C type rules
>> CODING_STYLE: add memory management rules
>> CODI
On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
wrote:
> On Thu, Aug 12, 2010 at 3:56 PM, malc wrote:
>>
>> While intentions of this are good, i believe this goes too far, i doubt
>> that the proposed additions are enforcable and have no doubts that they
>> will be widely ignored and at
On Thu, Aug 12, 2010 at 3:56 PM, malc wrote:
>
> While intentions of this are good, i believe this goes too far, i doubt
> that the proposed additions are enforcable and have no doubts that they
> will be widely ignored and at the same time provide more grounds for
> whining. Furthermore the exist
On Thu, 12 Aug 2010, Blue Swirl wrote:
> Add a few rules, based loosely on libvirt HACKING.
>
> Blue Swirl (5):
> CODING_STYLE: add preprocessor rules
> CODING_STYLE: add C type rules
> CODING_STYLE: add memory management rules
> CODING_STYLE: add string management rules
> CODING_STYLE:
Add a few rules, based loosely on libvirt HACKING.
Blue Swirl (5):
CODING_STYLE: add preprocessor rules
CODING_STYLE: add C type rules
CODING_STYLE: add memory management rules
CODING_STYLE: add string management rules
CODING_STYLE: add rules for printf-like functions
CODING_STYLE | 1
63 matches
Mail list logo
