[Qemu-devel] Re: commit rules for common git tree

[Michael S. Tsirkin]

On Tue, Dec 29, 2009 at 06:40:31PM +0100, Aurelien Jarno wrote:
> On Tue, Dec 29, 2009 at 07:23:28PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Dec 27, 2009 at 05:01:38PM -0600, Anthony Liguori wrote:
> > > Likewise, if you see a patch go in that you think would have benefited  
> > > from being on the list, point it out.
> > 
> > How *would* I see it? I guess I could write scripts that correlated git
> > logs (or qemu commit list if it is ever resurrected) with mailing list
> > archive.  If patch is not there, look in mailing list around the time
> > for a hint: could have explanation in the discussion. Or maybe it is
> > part of a series someone pushed ... you get the point.
> > 
> 
> All those commit have a single Signed-of-by: line. That decreases the
> number of patches to take.
> 
> Anyway I still don't really understand you are trying to achieve here,
> and without pointing to real problems, I am not sure we are going to
> understand.

What would you call real problems?
- You listed complains 3 times as an issue for committers.
  Is this a problem worth solving? I think my suggestions
  will help solve it.

- Even codewise: it's not uncommon for commit X to revert commit Y by
  another person, at least partially. I can point them out
  privately, prefer not to do it publically. This hurts git bisect and
  generally makes following history harder.  Unavoidable but seems less
  common with reviewed patches.

> The life of committers is not really easy, and the patch submitters do
> not really help to improve it:
> - a lot of patches are only reviewed by the committers, not so many
>   persons send Acked-by: mails.
> - you have to deal with code you don't understand
> - you have to track continuously respined series (with patches moving
>   from one to another, being merged or changing title)
> - you get complains when you review a patch
> - you get complains when you don't review a patch fast enough
> - you get complains after you applied a patch
> - etc...

Most complaints are result of somewhat opaque nature of the commit
process.  For example, people would complain "where's my patch" often to
be said: it is applied, not yet pushed. Sending mail "applied thanks"
would solve this.  I am suggesting making it more transparent and reduce
number of complaints. Thus life of committers will become easier :).

> This is not always fun. If you want to add more strict rules to the
> committers without reasons, you will just get the contrary effect and
> slow down the development process.

Yes we do not want a "process", but what I am suggesting is not
a process, is it? Just being open about what's going on.

-- 
MST