Re: [Qemu-devel] An organizational suggestion

[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 :-). I want to be very 
clear: my (and hopefully everybodys) intention with this discussion is to find 
an acceptable solution, not to play politics or something like that. I'm very 
grateful to all of the developers, because without them, we wouldn't be here. 
But it is always good (in my opinion at least) to aim high.

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) and after we have a 
somewhat comprehensive list, we can ask the committers to respond to them to 
see which is a workable alternative...

Best regards.


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html