Re: [Qemu-devel] An organizational suggestion

[Andreas Färber]

Am 03.06.2008 um 17:36 schrieb Balazs Attila-Mihaly (Cd-MaN):

> > I'd just like to point out that committing patches is easy. The  
> > hard (and time
> > consuming) bit is identifying, rejecting, fixing and/or making  
> > constructive
> > comments on all the bogus patches. The are lots of patches that  
> > fall into
> > this latter category, e.g. patches that have clearly only ever been  
> > tested on
> > x86 targets.
>
> I agree 100%. However I would like to point out that not all people  
> have (easy) access to other architectures. This could be resolved  
> partially by an automated testing framework (as I mentioned earlier)  
> and/or (preferably and) by a central repository of "do's" and  
> "dont's" (on a wiki for example :-).

> To make the discussion more focused, I propose that we come up with  
> a list of yes/no questions and committers (especially Fabrice)  
> express their opinion and we'll see what solutions are acceptable.  
> What I've seen so far:
>
> - Should patches be tracked (via an issue tracker, wiki or some  
> other solution)?
> - Should there exists a document describing "do's" and "dont's" for  
> Qemu source code?
> - Would an automated testing framework be useful?
>
> Please list your own questions (yes/no to keep it simple)

I don't think yes/no is helpful here.

Obviously patches need to be tracked, the question is not yes/no but  
how. "[PATCH]" in the subject has been one strategy to aid the  
maintainers in tracking them.

A document with contributor information might be a good idea. Whether  
this needs to be an external resource such as a Wiki is another  
question. A simple "CONTRIBUTING" text file in SVN trunk could do.(*)  
After all, it's the maintainers who decide, and it's the simplest way  
to diffuse the info into working copies and mirrors.

An automated testing framework is always useful, yes. Questions are  
who writes it, where does it run and what does it do. There are a  
couple of tests in the tests/ directory, but they do not seem portable  
(they don't compile on OSX/i386). Furthermore, some patches discussed  
recently were about theoretical situations that cannot easily be tested.

(*) Among the info that I would find useful is more transparency on  
whether there is a certain "objection time" before patches get  
committed, leading to said batch commits at unexpected times. Also  
some other events came surprising, such as the 0.9.1 release - other  
projects follow a procedure of branching and issuing a call for  
testing, or at least giving an advance notice for pending patches to  
be applied.

Andreas