From: Michal Simek <monstr@monstr.eu>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] asm-offsets: generate bd_t size
Date: Mon, 10 Jan 2011 17:04:16 +0100 [thread overview]
Message-ID: <4D2B2E00.8090306@monstr.eu> (raw)
In-Reply-To: <20110110104652.1735C150A44@gemini.denx.de>
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4D2ABA41.7030805@monstr.eu> you wrote:
>> I am little bit confused.
>> 1. Mike's patch has broken coding style in his patch ("space"+"space"15)
>
> Indeed. Sorry for missing this. The existing code had the same issue.
> If you want, then please submit a patch to clean this up for the whole
> file.
>
>> 2. I sent that patch 3 days before Mike. (It is the longer story)
>> http://lists.denx.de/pipermail/u-boot/2010-December/084095.html
>>
>> I like that the patch is in mainline tree because I need it for
>> Microblaze but I don't quite understand that you beat me about coding
>> style and then you apply patch which has broken coding style.
>>
>> I don't care if that patch is Mike's or mine I would like to be sure
>> what are that acceptance rules.
>>
>> Can you please tell me how this can happen?
>
> Usually I try to process incoming patches sequentially, but this is
> not always possible; even if I follow all mail threads this is
> unreliable as many people submit new versions of their patches without
> proper linking back to the existing threads. So even when trying to
> work mostly sequentially, I will frequently jump forward and backward
> in time.
>
> In cases like this (different patches for the same thing, submitted
> independently by separate people using different Subjects) it is
> pretty much pure chance which of the submitted patches gets picked up.
> For me the only important thing is that no patches get dropped
> unintentionally.
>
>
> If I remember correctly Mike's patch was part of my todo list in
> patchwork, which was what I processed first, completely independent of
> submission date. I don't remember if I moved the patch there myself,
> or if somebody else (Mike?) bestowed it upon me.
You don't need to "apologize". I really appreciate your work and it is
not easy to handle everything. For me is important to fix microblaze
code and doesn't matter who has done that patch.
My point was that you always look at coding style and would be nice to
check it all the time and doesn't matter who send it even you. I
understand that it is hard to check your own work.
Best regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
prev parent reply other threads:[~2011-01-10 16:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-24 17:57 [U-Boot] [PATCH] asm-offsets: generate bd_t size Mike Frysinger
2011-01-09 17:08 ` Wolfgang Denk
2011-01-10 7:50 ` Michal Simek
2011-01-10 9:41 ` Mike Frysinger
2011-01-10 10:57 ` Wolfgang Denk
2011-01-10 15:57 ` Michal Simek
2011-01-10 10:46 ` Wolfgang Denk
2011-01-10 16:04 ` Michal Simek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2B2E00.8090306@monstr.eu \
--to=monstr@monstr.eu \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox