Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting)

[malc]

On Sun, 6 May 2012, Blue Swirl wrote:

> On Sun, May 6, 2012 at 9:46 AM, malc <address@hidden> wrote:
> > On Sun, 6 May 2012, Blue Swirl wrote:
> >
> >> On Sun, May 6, 2012 at 9:03 AM, malc <address@hidden> wrote:
> >> > On Sun, 6 May 2012, Blue Swirl wrote:
> >> >
> >> >> On Fri, May 4, 2012 at 2:37 AM, malc <address@hidden> wrote:
> >> >> > On Fri, 4 May 2012, Andreas F?rber wrote:
> >> >> >
> >> >> >> Am 04.05.2012 02:41, schrieb Anthony Liguori:
> >> >> >> > On 05/03/2012 02:58 PM, Peter Maydell wrote:
> >> >> >> >> On 9 February 2012 13:46, Anthony Liguori<address@hidden>  wrote:
> >> >> >> >>> On 02/09/2012 03:48 AM, Markus Armbruster wrote:
> >> >> >> >>>> You buried the one truly important sentence, let me dig it out 
> >> >> >> >>>> for you:
> >> >> >> >>>>
> >> >> >> >>>>          *** Patches should always go to the mailing list ***
> >> >> >> >>>>
> >> >> >> >>>> Exceptions need justification.  Responsible handling embargoed 
> >> >> >> >>>> security
> >> >> >> >>>> issues may qualify.  Style fixes certainly not.
> >> >> >> >>>
> >> >> >> >>> 100% agreed.
> >> >> >> >>
> >> >> >> >> I don't see anything in the mailing list archives corresponding
> >> >> >> >> to commits f05ae537, f6af014e.
> >> >> >> >>
> >> >> >> >> No unreviewed patches should go double when we're in hardfreeze!
> >> >> >> >
> >> >> >> > These patches are admittedly trivial but it is important to stress 
> >> >> >> > the
> >> >> >> > point that all patches need to go on the mailing list before being
> >> >> >> > committed.
> >> >> >> >
> >> >> >> > It's an important part of keeping the development process 
> >> >> >> > inclusive.  I
> >> >> >> > don't think it's reasonable to ask for an Acked-by on something as
> >> >> >> > simple as indentation changes but at the same time, there's no 
> >> >> >> > reason
> >> >> >> > not to just post patches.
> >> >> >>
> >> >> >> The second patch is far from trivial!
> >> >> >>
> >> >> >> It unneededly breaks the build on ppc hosts (during the Hard 
> >> >> >> Freeze!),
> >> >> >> so that I can no longer compile-test my patch series against 
> >> >> >> PowerKVM.
> >> >> >
> >> >> > As discussed on IRC, the feature does not work on PPC32, hence it's
> >> >> > violently disabled, what's needed is a black/white list of AREG0 ready
> >> >> > targets.
> >> >>
> >> >> I think disabling was a poor decision, didn't this code already work
> >> >> in some cases? What's really needed is to shuffle the registers
> >> >
> >> > It didn't on Linux and BSDs, might have worked on Darwin and AIX.
> >>
> >> Then fix it, please!
> >
> > WTF? You commit broken code that is used by 9/10 of all PPC users (yes
> > all 9 of them) and _then_, not before, demand to fix it.. shrug.
> 
> The same approach worked fine on x86. I don't know all architectures
> and their ABIs, so I can't fix all back ends. You should be able to do
> this much better. Is fixing the register order that hard?

Yet you commit broken code without consulting the person who does know
it, that's the gist of the matter.

> 
> >
> >>
> >> >> according to ABI and this shouldn't be much different to what was
> >> >> already in.
> >> >
> >> > The code that was commited was
> >> > a. Pathetically inneficient everywhere
> >> > b. Wrong for SysV ABI
> >>
> >> Yes, that's what I told back then. There are too many ABIs for various
> >> architectures, the maintainers should know these much better.
> >
> > Told whom?
> 
> The list at least, there were plenty of people involved in the discussions.

Myself excluded for whatever reason.

> 
> >
> >>
> >> >
> >> >>
> >> >> I have sent out AREG0 patches for ARM and PPC, also I have x86 patches
> >> >> in preparation. When (if) these and maybe further conversions are
> >> >> committed for 1.2, PPC host support will be practically nonexistent.
> >> >> Is this what you want?
> >> >
> >> > What i do not want is code that doesn't work. And i take non-existant
> >> > over wrong any day. I also would prefer to be notified when code which
> >> > i maintain is modified.
> >>
> >> But your approach is not OK in any sense, now we have a failed build.
> >> Before, we had code that could work in some cases and the other cases
> >> could be probably easily fixed.
> >>
> >
> > Well, here's a "sense", code that _silently_ misbehaves is NOT "OK".
> 
> Then fix the misbehaviour instead of this error approach, please.
> 

Please do read your e-mail, in particular messages from Andreas.

-- 
mailto:address@hidden