On Mon, Apr 15, 2013 at 10:55 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: [...] > 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. Sure, i think so. > > 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. Yup, i think so too. > > 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. > Maybe it should be like this. Renaming jobs may be more comfortable for GSOC. Thanks for your comments. -- Thanks Harry Wei -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list