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

[Blue Swirl]

On Sun, Dec 27, 2009 at 4:40 PM, Michael S. Tsirkin <address@hidden> wrote:
> On Sun, Dec 27, 2009 at 04:12:37PM +0000, Blue Swirl wrote:
>> On Sun, Dec 27, 2009 at 11:37 AM, Michael S. Tsirkin <address@hidden> wrote:
>> > I'd like to discuss two questions related to changes that
>> > are committed to the shared tree.
>> > 1. A lot of patches are committed without being posted
>> >   to the list first, thus they go in without review.
>> >   Why is this good? Can this be addressed?
>>
>> Good or bad, this has always been the workflow.
>
> This made sense with CVS where it's hard to develop otherwise.  With git
> anyone can keep on development in a personal tree.  There are no
> advantages to pushing unreviewed changes that I can see.

The review is never complete and it does not catch all bugs. At some
point it's better to push the patches to a tree where they are getting
some testing. Currently only the master tree, stable trees and
Anthony's tree get some attention from testers.

>> > 2. When a change is committed to the tree, often no notification is sent
>> >   to the author.
>> >   Why is it a good idea to ask everyone to subscribe to qemu commits
>> >   list as well? Can 'applied thanks' mail be sent to patch authors?
>>
>> In the good old times, CVS commit messages went also to qemu-devel
>> list. That may no longer be technically possible or even desirable
>> because of the volume. I think qemu-commits sends the message to the
>> qemu-commits list and the author, so the 'applied, thanks' shouldn't
>> be needed if the list worked reliably.
>
> This does not work and never did.  mail can also be sent earlier than
> patch it pushed to a common tree: once someone else starts tracking
> patch in his tree, controbutor can stop tracking it.

In that model (Linux) we'd need a set of official second level trees
with maintainers who also test the patches heavily. Unlike Linux, we
don't have an unlimited supply of developers capable of acting as a
second level maintainer. Also QEMU does not have many independent
subsystems that could be delegated to the lieutenants.