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 :|