[LinuxBIOS] "Trivial" patches

[Torsten Duwe]

On Saturday 24 November 2007, Carl-Daniel Hailfinger wrote:
> On 21.11.2007 00:30, Torsten Duwe wrote:
> > Seconded. A "trivial" patch must _never_ break anything. Leave that
> > basically to each committer's judgement. If it does break something,
> > flame at will; we all make mistakes, but the blame must hurt ;-) In the
> > long run, someone incapable of forseeing such breakage should not retain
> > commit rights, IMHO.
>
> Removing commit rights of a person is surely a drastic measure, and the
> only one that works in case we don't enforce sane behaviour in the
> commit hooks. If I had my commit rights revoked, I'd probably feel
> offended very much.

Think about the amount of offense you had to cause before that happens.
Again: >>A "trivial" patch must _never_ break anything<<. When in doubt, ask 
for ACK, better safe than sorry. There must be some ultima ratio if constant 
blaming does not help, that's my point. Commit hooks are of very little help, 
and tend to get abused in some environments.

> > Besides that, do we agree that at least adding a new function or macro is
> > non-trivial (by definition, if you like)? This would also cover
> > refactoring and the design of new subsystems and would allow to split out
> > a new file from an existing big one OTOH.
>
> By that logic, adding a new file is non-trivial as well. Nice. The
> conditions above surely can be checked in a commit hook.

If it contains either new functions or new macros. Pulling definitions from 
a .c-file into a new header can be considered trivial sometimes. If you try 
to automate the recognition of all "trivial" patches you'll surely generate 
false rejects.

	Torsten