[DISCUSS]: hosting of source code that doesn't belong to the office directly

[Jürgen Schmidt <jo...@googlemail.com>]

Hi,

somebody has already asked for the OOo NetBeans plugin that is a useful 
tool for extensions developers. And it seems that there is interest to 
improve the plugin and make it ready for the latest NetBeans versions. 
The source code is part of the SGA but not yet available in our repo.

I have a general question. Where do we want to host such code or such 
sub projects that are somewhat independent of the office code and should 
be kept separately from my point of view. Means i wouldn't check in 
these projects under trunk.

Instead i would propose a further svn tree where we can host such 
projects. But i am not sure which name would be appropriate.

In this specific case it is a development tool for extension developers 
and i can think of a similar tool for Eclipse in the future. How about a 
further svn tree "devtools".

Any ideas or opinions?

Juergen

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Ross Gardler <rg...@opendirective.com>]

Sent from my mobile device, please forgive errors and brevity.
On Dec 6, 2011 9:41 AM, "Jürgen Schmidt" <jo...@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"<pe...@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.
>>>
>>
>

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Jürgen Schmidt <jo...@googlemail.com>]

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"<pe...@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.
>>
>

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Ross Gardler <rg...@opendirective.com>]

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?

Sent from my mobile device, please forgive errors and brevity.
On Dec 3, 2011 9:01 PM, "Andrea Pescetti" <pe...@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.
>

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Andrea Pescetti <pe...@openoffice.org>]

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.

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Carl Marcum <cm...@apache.org>]

On 11/30/2011 12:10 PM, Jürgen Schmidt wrote:
> On 11/30/11 1:31 PM, Rob Weir wrote:
>> 2011/11/30 Jürgen Schmidt<jo...@googlemail.com>:
>>> Hi,
>>>
>>> somebody has already asked for the OOo NetBeans plugin that is a
>>> useful tool
>>> for extensions developers. And it seems that there is interest to
>>> improve
>>> the plugin and make it ready for the latest NetBeans versions. The
>>> source
>>> code is part of the SGA but not yet available in our repo.
>>>
>>> I have a general question. Where do we want to host such code or such
>>> sub
>>> projects that are somewhat independent of the office code and should
>>> be kept
>>> separately from my point of view. Means i wouldn't check in these
>>> projects
>>> under trunk.
>>>
>>> Instead i would propose a further svn tree where we can host such
>>> projects.
>>> But i am not sure which name would be appropriate.
>>>
>>
>> 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.
>
>>
>>> In this specific case it is a development tool for extension
>>> developers and
>>> i can think of a similar tool for Eclipse in the future. How about a
>>> further
>>> svn tree "devtools".
>>>
>>
>> Another question is how we think these extensions would be released?
>> As part of (or in sync with) and AOO release? If so, we might want
>> this under the same trunk dir, so they can be easily tagged and
>> branched with the reset of the AOO release. But if we see these
>> extensions as having an independent release cycle, not tied to AOO,
>> then maybe they have an independent SVN tree.
>
> I think we will not release such a dev tool with the office. We will
> potentially align it if necessary and if changes in the office require
> changes in the NB plugin or other potential extensions as well. But in
> general we should keep this independent. It allows us more flexibility.
>
> I would prefer a new SVN tree and if nobody raised any concerns i would
> move forward with a further "extensions" tree besides "trunk".
>
> Juergen
>

+1 on the additional extensions tree.

Do we have an idea when well see the code?

I would like to help on bringing this up to date. I really miss having 
it in NB 7.0.

Best regards,
Carl

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Jürgen Schmidt <jo...@googlemail.com>]

On 11/30/11 1:31 PM, Rob Weir wrote:
> 2011/11/30 Jürgen Schmidt<jo...@googlemail.com>:
>> Hi,
>>
>> somebody has already asked for the OOo NetBeans plugin that is a useful tool
>> for extensions developers. And it seems that there is interest to improve
>> the plugin and make it ready for the latest NetBeans versions. The source
>> code is part of the SGA but not yet available in our repo.
>>
>> I have a general question. Where do we want to host such code or such sub
>> projects that are somewhat independent of the office code and should be kept
>> separately from my point of view. Means i wouldn't check in these projects
>> under trunk.
>>
>> Instead i would propose a further svn tree where we can host such projects.
>> But i am not sure which name would be appropriate.
>>
>
> 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.

>
>> In this specific case it is a development tool for extension developers and
>> i can think of a similar tool for Eclipse in the future. How about a further
>> svn tree "devtools".
>>
>
> Another question is how we think these extensions would be released?
> As part of (or in sync with) and AOO release?  If so, we might want
> this under the same trunk dir, so they can be easily tagged and
> branched with the reset of the AOO release.  But if we see these
> extensions as having an independent release cycle, not tied to AOO,
> then maybe they have an independent SVN tree.

I think we will not release such a dev tool with the office. We will 
potentially align it if necessary and if changes in the office require 
changes in the NB plugin or other potential extensions as well. But in 
general we should keep this independent. It allows us more flexibility.

I would prefer a new SVN tree and if nobody raised any concerns i would 
move forward with a further "extensions" tree besides "trunk".

Juergen

Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly

[Rob Weir <ro...@apache.org>]

2011/11/30 Jürgen Schmidt <jo...@googlemail.com>:
> Hi,
>
> somebody has already asked for the OOo NetBeans plugin that is a useful tool
> for extensions developers. And it seems that there is interest to improve
> the plugin and make it ready for the latest NetBeans versions. The source
> code is part of the SGA but not yet available in our repo.
>
> I have a general question. Where do we want to host such code or such sub
> projects that are somewhat independent of the office code and should be kept
> separately from my point of view. Means i wouldn't check in these projects
> under trunk.
>
> Instead i would propose a further svn tree where we can host such projects.
> But i am not sure which name would be appropriate.
>

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.

> In this specific case it is a development tool for extension developers and
> i can think of a similar tool for Eclipse in the future. How about a further
> svn tree "devtools".
>

Another question is how we think these extensions would be released?
As part of (or in sync with) and AOO release?  If so, we might want
this under the same trunk dir, so they can be easily tagged and
branched with the reset of the AOO release.  But if we see these
extensions as having an independent release cycle, not tied to AOO,
then maybe they have an independent SVN tree.

> Any ideas or opinions?
>
> Juergen