[LinuxBIOS] "Trivial" patches

[Uwe Hermann]

On Tue, Nov 20, 2007 at 07:40:26PM +0100, Carl-Daniel Hailfinger wrote:
> On 20.11.2007 19:20, ron minnich wrote:
> > On Nov 20, 2007 10:20 AM, Carl-Daniel Hailfinger
> > <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> >
> >   
> >> various big code changes/additions have been committed as trivial by
> >> others in the past, so I am considering to follow the same policy and
> >> declare all of my future patches as trivial and commit them instantly if
> >> I feel like it. That would surely speed up development for me.
> >>
> >> Comments/Flames/Applause welcome.
> >>     
> >
> > no, you should take us to task when we make that mistake, and I'm
> > sorry if I have done it too much myself.
> >
> > Let's stick to the process, and try to flag violations of the process.
> >   
> 
> OK, can we decide on what should be (not) allowed, preferably as regexp
> for the diff?

Please don't over-engineer this. It's fine to just flame the committer
who did a trivial commit without it being really trivial (yeah, I know,
I'm guilty of this sometimes too).

In the worst case, if the commit really _breaks_ something or is
wrong and there's opposition, we can just revert it (which I did
in the past, too, with one of my "trivial" fixes).


> Suggestion for NOT allowed stuff:
> * Adding files (if they were forgotten in the previous non-trivial
> commit, reuse the Ack from there)

Why? I think this should be allowed. If the whole patch was acked and
you simply forget to 'svn add' a file (i.e. commit only parts of the
patch) it's perfectly valid to commit the forgotten file with that ACK.


> * Changing code unless it is a build fix and has "build fix" in the
> commit log

No, I don't think we want this to be _that_ daunting. Even code changes
can be "trivial" (wrong word maybe, "obviously correct" might be better)
sometimes. I don't think we should restrict this to comment changes only.

Good examples are the "constify" patches, using PCI ID #defines instead of
the hard-coded numbers, and similar stuff.


> Checking for added files in the commit hook is easy. Finding out whether
> a patch touches code or comments is difficult. My idea is to strip
> comments from the file before and after modification, then run "diff
> -uw" on both versions.

Overkill, IMO. Just flame whoever did crap, in the worst case we revert
the patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org