On Mon, Apr 15, 2013 at 09:43:55PM +0800, harryxiyou wrote: > On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > [...] > > I'm not hugely comfortable with the idea of "capability support" being > > done by a student. IMHO to do a good job on that design-wise requires > > someone with a very good understanding of libvirt architecture & application > > needs. > > > > I understand. However, i think our Libvirt is developing so we should give more > choices to learners who are very interested in some field of Libvirt.(Like me, i > love the storage system of Libvirt very much). Maybe this is the essence of > GSOC, isn't it? Actually, some student is not only interested in > Libvirt but also > wanna to join this community and contribute to this community forever. (Like > me, i love the community because i can learn more knowledge from it.) > I believe that interest is the best teacher. No matter how the problem is > difficulty i will try my best to achieve it if i am very interested > in it. Another > key point is that GSOC just let students join the community and finish easy > jobs firstly. GSOC wanna train more core developers for our community. If i > can finish a job a bit difficulty, i can also accomplish it after GSOC > continuously. > All in all, i think you should not worry about this matter ;-). Enthusiasm of the students to learn libvirt isn't the only consideration. The project mentors have to put non-trivial effort into GSoC and want to have some level of confidence that the project will result in a positive outcome for both the student & the project. I think a project looking at adding 'rename' API support for all objects in libvirt has a high liklihood of success, since it is a clearly defined problem with easily measurable success criteria and a fairly unambiguous design to follow that will not require much debate. A project looking at "capabilities" has a much lower liklihood of success because it very focused on architectural design. Getting such design right requires significant knowledge of libvirt, and will require significant debate & discussion by many parties on the list. Design discussions of this kind pay no attention to any external deadlines, that programs like GSoC have. I'm not saying a student couldn't write something, but I'm not confident that the result would be something we'd be prepared to merge, and by that benchmark could be considered a failure. I think GSoC projects should focus on something where the design is clearly defined upfront, and the task is mostly about learning the libvirt codebase & getting a thorough implementation done. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list