[LinuxBIOS] r2550 - trunk/LinuxBIOSv2/util/flashrom

[Segher Boessenkool]

>>> Whats missing in http://www.linuxbios.org/Development_Guidelines?
>>
>> The doc should be in the repo itself.
>
> OK, I'll send a patch soon.

Great, thanks.

>> Other than that,
>> it could be formalised a bit ;-)
>
> Do you have a patch or specific suggestions for improvements?

Nope, I can't say I'm good at writing pseudo-legalese
myself.

>> I'm not saying the review process is useless; I'm saying
>> that recording history of who thought what patch was a
>> good idea, _when those patches never end up being committed_,
>> is pretty damn useless.  A newer version of the patch
>> superseded the old one; knowing who approved the final
>> commit *can* of course be useful.  I wasn't commenting
>> on the review process at all; just on the acked-by lines
>> that people add to commit messages.
>
> OK, how about this procedure (I don't really care anymore whether
> it's compatible with the way it works in Linux, it should only be
> legally "bullet-proof"):
>
> * Everyone who creates or modifies a patch adds his Signed-off-by.
>
> * The person who finally commits the patch adds his/her
>   Signed-off-by, too (if it's not already there anyway).

In the Linux logs, there's also an "Author:" field next to
the patch subjects and date; normally it's automatically
picked up from the "From:" line on the email patch (or from
an explicit "From:" line in the patch).  LinuxBIOS might
want to have this author information more explicit, too
(yes almost always the author is the same as the first
signed-off-by, but there can be multiple authors for a
patch, or the sign-off is done by someone else than the
author, someone from the same company for example).

> * The Acked-by is completely separated from that.

Exactly.

> You send an Acked-by
>   when you think this patch can be committed.
>   You don't have to modify a patch for an Acked-by, you can just send
>   it to say "I think this patch is ok".
>
> * If a certain version of a patch received two Acked-by's by two
>   different people, it can be committed.
>   Ergo, every commit message will have 1 or more Signed-off-by lines 
> which
>   build a "chain of trust" for legal reasons, _and_ it will have 2 or 
> more
>   Acked-by lines which enforce our review process.
>
> * The Acked-by's must be for exactly the same version of the patch.
>   Acked-by's for previous versions of the patch are meaningless, they
>   are not added to the commit message, only those for the exact
>   incarnation of the patch which gets committed.

Sounds all fine to me.

> * So yes, it is possible to post
>
>    - A patch with only a Sign-off-by:
>      You modified the code, but don't want it to be committed, yet.

You better state that "it's not ready yet" explicitly too
in such a case, to avoid confusion.

>    - A patch with a Signed-off-by and an Acked-by:
>      You modified the patch and you think it can be commited.

That's the normal case.  I think ack'ing your own
patches is pretty meaningless (you cannot really
review your own patches) but maybe that's just me.

>    - An email with just an Acked-by:
>      You didn't touch the patch at all, but you think it can be 
> committed.

If your ACK is the last needed one, you can just go
ahead and commit the patch and send an email stating
you did that.  The eventual committer has to type
in the acked-by lines anyway.

> Comments?

Just one about process: it is good practice to keep
the signed-off-by in the patch itself, so you won't
mess-em up.  Patch maintenance tools like quilt can
help here.


Segher