From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Report from the Buildroot Developer Day
Date: Mon, 7 Nov 2011 13:25:48 +0100 [thread overview]
Message-ID: <20111107132548.33965b56@skate> (raw)
In-Reply-To: <20111107120936.GA26160@merkur.ravnborg.org>
Le Mon, 7 Nov 2011 13:09:36 +0100,
Sam Ravnborg <sam@ravnborg.org> a ?crit :
> The tags seems to be used in different ways. The way I have understood
> their usage - and thus the way I have used them is like this:
>
> Acked-by is used when I think that a patch does the right thing.
> For example when it introduces a a new feature or change something -
> and which I consider it the right thing to do.
>
> Reviewed-by is stronger in the sense that I have actually taking my
> time to carefully read the patch line-by-line and that I consider
> that the patch is correct.
> I almost never use "Reviewed-by" for patches touching code areas
> that I am not familiar with - as I do not know if they are correct.
> Reviewed-by includes an implicit Acked-by as I would not spend time
> to review something if I did not agree on the patch.
Interestingly, my understanding is more or less the opposite of yours.
For me:
* Reviewed-by means that you have read the patch and agree with its
principle and general implementation, but not that you have actually
tested and verified that the patch works. The top-level maintainer
will have to do additional testing because you haven't done so.
* Acked-by is much stronger, as it means that you fully agree with the
patch, that you reviewed it *and* tested it, and that the top-level
maintainer does not necessarily need to do additional testing if he
trusts you, because Acked-by means that you have actually tested
this.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2011-11-07 12:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-02 15:03 [Buildroot] Report from the Buildroot Developer Day Thomas Petazzoni
2011-11-02 20:15 ` Peter Korsgaard
2011-11-04 11:56 ` Luca Ceresoli
2011-11-04 12:30 ` Michael S. Zick
2011-11-07 16:17 ` Peter Korsgaard
2011-11-07 9:58 ` Thomas De Schampheleire
2011-11-07 12:09 ` Sam Ravnborg
2011-11-07 12:25 ` Thomas Petazzoni [this message]
2011-11-07 12:39 ` Yann E. MORIN
2011-11-08 13:20 ` Thomas De Schampheleire
2011-11-07 12:39 ` Thomas Petazzoni
2011-11-07 19:01 ` Yann E. MORIN
2011-11-08 8:19 ` Thomas De Schampheleire
2011-11-15 22:17 ` Arnout Vandecappelle
2011-11-15 23:28 ` Michael S. Zick
2011-11-17 13:57 ` Thomas De Schampheleire
2011-11-17 21:21 ` Bjørn Forsman
2011-11-18 6:39 ` Thomas De Schampheleire
2011-11-18 11:04 ` Bjørn Forsman
2011-11-18 11:36 ` Thomas De Schampheleire
2011-11-18 17:51 ` Arnout Vandecappelle
2011-11-18 22:53 ` Peter Korsgaard
2011-11-18 23:16 ` Arnout Vandecappelle
2011-11-19 8:24 ` Peter Korsgaard
2011-11-20 8:36 ` Thomas Petazzoni
2011-11-20 9:58 ` Peter Korsgaard
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=20111107132548.33965b56@skate \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.