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