Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] ARC: gcc - Fix SIZE_TYPE to be "unsigned int" instead of long unsigned int"
Date: Mon, 15 Sep 2014 16:55:57 +0200	[thread overview]
Message-ID: <20140915165557.2536d76d@free-electrons.com> (raw)
In-Reply-To: <1410792116.5875.43.camel@abrodkin-8560l.internal.synopsys.com>

Dear Alexey Brodkin,

On Mon, 15 Sep 2014 14:41:57 +0000, Alexey Brodkin wrote:

> > We have a stupid rule, and stupid rules are meant to be complied
> > with :-)
> 
> Understood - uniformity is good even if the rule itself is not that
> good :)

Absolutely :)

> Funny enough that initially I had the same comment in the patch itself,
> but while looking at output of "git format-patch" I found myself a bit
> frustrated - if I were a reviewer I would say that submitted "full"
> patch looks ridiculous.
> 
> Then I removed comment from commit message. That made me think that you
> guys won't apply a patch that won't show any useful info in git log. 
> 
> So I decided to move a message to the Buildroot commit. This made sense
> for me because at least when I bump version of a package I look at
> history of this package and this way try to figure out what's still
> required and what's not.

Hehe, funny. No problem if there is actually some duplication between
the git commit log, and the patch description itself.

> Moreover looking at the next folder "package/gcc/4.9.1" I found that
> half of patches don't have any comment inside, some have URLs to
> bugs/commits in GCC, some are full-scale patches with verbose
> description.

Half of the patches are carried over since gcc 4.2 or so, in a pre-2008
era, at a point where the state of Buildroot was clearly not as good as
it is today. I think you wouldn't want to look at a pre-2008 Buildroot
tree :-)

That being said, is your comment an indication that you volunteer to do
some research about these patches, write proper descriptions, or even
better help getting them merged upstream? :-)

Joke aside again, it's by having less and less patches with no
description that at some point all patches in Buildroot will have a
description. This way nobody will feel your frustration because it will
just appear to be the "normal thing".

> Now you may understand my frustration.

Yes, of course, I do understand.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

      reply	other threads:[~2014-09-15 14:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 13:26 [Buildroot] [PATCH] ARC: gcc - Fix SIZE_TYPE to be "unsigned int" instead of long unsigned int" Alexey Brodkin
2014-09-15 13:50 ` Thomas Petazzoni
2014-09-15 14:06   ` Alexey Brodkin
2014-09-15 14:29     ` Thomas Petazzoni
2014-09-15 14:41       ` Alexey Brodkin
2014-09-15 14:55         ` Thomas Petazzoni [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=20140915165557.2536d76d@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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