Sent from my mobile device, please forgive errors and brevity. On Dec 6, 2011 9:41 AM, "Jürgen Schmidt" <[email protected]> wrote: > > On 12/6/11 9:07 AM, Ross Gardler wrote: >> >> I've not seen any discussion of IP management in these extensions. All >> contributions would have to be made with an ICLA on file, all licenses >> would have to be acceptable and releases would have to be managed properly. >> Similarly development of the choose would be community led. Does the PPMC >> want to take on this responsibility? Will authors of these "extensions" >> want to work this way? > > > It should be obvious but nevertheless an interesting question! If somebody would like to develop an extension and would like to put it in our repo she/he has to be a committer. And all rules for normal contributions are valid. > > The question for the release process is much more interesting. > > In case of the NB plugin i see no problem to manage releases in an Apache conform way. Maybe we have to double check if it is allowed to host and develop a plugin for a CDDL 1.0/GPL v2 IDE or if developed plugins have any incompatible license restrictions. >
No problem with this, its only if we are distributing code we care. > If we want to develop extension here as well, our own extension repository becomes more important and would be the natural way to manage releases. At least from my point of view and probably not 100% Apache conform. > > But we should think about the way people search and install extensions today. Most often they get notice about an extension somewhere, go to the extension repository and install it. Or they simply browse the ext repo and simply install and try an interesting one. Searching for a concrete ext is probably also a valid approach. The question here would be more how we could align such a development and release with Apache. A source release is probably less important and interesting for most of the users. But having the code available is of course important to reuse existing stuff for new extensions. > > And more questions comes into my mind. Do we want to support extensions development under the umbrella of Apache? I think it is a good way to attract new developers, starting with extensions and do more and more work in the office code base in parallel. Often base code have to be changed, extended to make things possible via extensions. > > Well we can also go the easier way and can move extension development to somewhere else but that is not optimal from my pov and we should try to bind developers to Apache. Make it interesting to work here in this environment. > > Juergen > > >> >> Sent from my mobile device, please forgive errors and brevity. >> On Dec 3, 2011 9:01 PM, "Andrea Pescetti"<[email protected]> wrote: >> >>> On 30/11/2011 Jürgen Schmidt wrote: >>> >>>> On 11/30/11 1:31 PM, Rob Weir wrote: >>>> >>>>> Maybe just call it "extensions" ? This could be the root for >>>>> "standard extensions" that are produced by this project. Some might >>>>> be app dev related. But we might have other standard extensions in the >>>>> future, e.g., a CMIS extension using Apache Chemistry. >>>>> >>>> >>>> i thought about "extensions" but in this particular case it is not an >>>> extension in the classical manner. But it is a developer tool for >>>> extensions and could be of course hosted there as well. >>>> >>> >>> Then it would be clearer to use "extensions" for stuff that will >>> eventually be packaged into .oxt files, and "tools" or "devtools" for the >>> current use case, which is much more relaed to development than to >>> extensions. Not that I have a strong opinion on this; "extensions" just >>> seems potentially confusing for an editor plugin. >>> >>> Regards, >>> Andrea. >>> >> >
