On Thu, May 28, 2009 at 01:02:08PM -0400, Dave Allan wrote:
Daniel Veillard wrote:
On Wed, May 27, 2009 at 01:08:04PM -0400, David Allan wrote:
---
Looks good but IMHO it misses one of the main point, it focuses only on the technical aspects of the submission but not at all on the process and interraction with the list. Basically, before engaging in adding a new API for libvirt, the best is to discuss a first draft of the suggested changes to libvirt.h, then make sure it gets reviewed, and start developping the code only after a first on-list validation step. There is nothing worse than working a week on a patch sending it to the list and learning that the thing could not work because it breaks some preestablished rules. I think the most common example would be a patch to add raw extra qemu command line options to the API :-)
That's a good point. I deliberately limited the document to the technical aspects of the work, but I do agree that people need to be told right at the start about the need to participate in the discussion before anything; I'll add that.
We should (i.e., you guys who have been here since the beginning should) list the the current pre-established rules and I can put them in a separate doc/wiki page and link to it from my doc. Would that work?
Yeah, I think the general development process guidelines should be separate from your doc, which is about technicalities of adding new APIs. If Rich dones't mind, we should probably incorporate a large chunk of this page into a 'process guidelines' page http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/ Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|