incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly
Date Tue, 06 Dec 2011 13:37:26 GMT
Sent from my mobile device, please forgive errors and brevity.
On Dec 6, 2011 9:41 AM, "Jürgen Schmidt" <jogischmidt@googlemail.com> 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"<pescetti@openoffice.org>
 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.
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message