On Wed, Feb 06, 2013 at 12:22:35PM +0000, Donal Lafferty wrote: > Okay, so the context for adding the phase 1 Hyper-V plugin to the actual > release was to smooth the way for newbies. Adding features to the community > code can be tricky for non-committers. Recall that last week I posted > details on how to submit a multi-commit patch for review :) > > With that in mind, here are the latest issues: > > 1. The IP concerns were a bit of a surprise, because IP expectations are not > covered in the Design Doc template. Would anyone object if I updated > https://cwiki.apache.org/CLOUDSTACK/design-document-template.html with a > heading on 'IP Clearance' and a summary of Chip's comments (with references > to orginal mailing list discussions)? >
I'd rather see it updated with something about (1) what dependencies will you be adding to the project, and (2) are you expecting to include any code developed outside the Apache CloudStack project. I don't want to get into specifics in the template, and would rather have the proposer bring the specific questions to the dev list for discussion. I do like the idea of triggering the thought in the proposer's mind early though! ;-) > 2. The Hyper-V patch includes fixes to cores CloudStack. Is the submission > process for these fixes a) raise a defect, b) submit patch? > If there are fixes to be brought into the core, I think they should be separated out as defects with accompanying patches. Otherwise, the feature itself may be confused with the patches to fix existing bugs. > 3. Feedback on the submission isn't captured in the Review Board > submissions. Any objections to adding the points that David Nalley raises to > the Review Board entry, and closing it? > No objection... please do! > 4. Finally, where is the best place for 3rd party plugins? This point was > raised in relation to the API client for C#. Any preferences for leaving 3rd > party material stay in the developer's repo, or the 'extras' repo? > The term 3rd party confuses me. In your example, you were talking about a .NET API wrapper, correct? Are you not the author? Generally though, we haven't decided if we want API bindings to be in the project itself. For example, I know of python (not Marvin), ruby (which I wrote), PHP, and other bindings that are outside of our CS repo. Are you proposing that we start building up a set of canonical API wrappers within the project itself? > DL >
