incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <>
Subject Re: Extensions hosting
Date Wed, 04 Jan 2012 21:22:15 GMT
Hi all, this is Roberto Galoppini (SourceForge),

I'd like to clarify a couple of things about what we're able to offer.

2012/1/4 Jürgen Schmidt <>:
> On 1/3/12 5:25 PM, Rob Weir wrote:
>> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
>> <>  wrote:
>>> As the community know Gav, in his role at infrastructure@ has
>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>> infrastructure. His work has been progressing and he remains committed
>>> to completing this.
>>> However, as some know Sourceforge made an offer to help via our
>>> private list. At the time they did not want to discuss this topic in
>>> public for a number of reasons. I've had a couple of chats with
>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>> why the ASF prefers to host all services for its projects. In response
>>> SF have tailored their offer of support.
>> Thanks for the wonderful job of reaching out to SourceForge and
>> connecting us to this offer, Ross.
>>> I relayed the outline of our conversations to the infrastructure team
>>> who have asked me to have the AOO project provide some feedback, via a
>>> board report, on what problems the AOO project forsee for the
>>> extensions site and what options are available, if possible a
>>> recommendation for an optimal solution should also be made. Note that
>>> we can submit something out of cycle if we want, the next full report
>>> is not due till March.
>> This has already been discussed, in detail in a previous thread:
>> I believe that discussion is what prompted Gavin to action.  If
>> someone wants to copy and paste that into a Board report, then they
>> are welcome to do so.
>>> The reason infra@ have escalated to board@ is probably that we need to
>>> figure out a long term solution for the AOO project and that solution
>>> is heavily influenced by ASF policy. Any solution that we are
>>> currently considering will have an impact on the AOO extensions site
>>> and/or on ASF policy.
>>> The current situation, as I understand it, is that the board have
>>> given permission for the extensions site to be managed by infra during
>>> incubation. The problem of distributing content under licences other
>>> than Apache is not seen to be a problem during the incubation process.
>>> Beyond incubation the board has delegated responsibility to the
>>> Incubator PMC. I don't believe that particular discussion has been
>>> started yet.
>>> Gav tells us that he has been thinking about making the extensions
>>> site an index site, thus allowing the extensions to be housed
>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>> corporation or wherever). This would neatly bypass the licence
>>> problem. Open source extensions needing hosting could go to
>>> apache-extras while commercially licensed extensions would need to
>>> provide their own hosting.
>> That was my recommendation as well, in the previous thread referenced
>> above.  It is more work up front, but the resulting "directory" of
>> links and metadata associated with extensions (and templates -- don't
>> forget the templates) is very flexible.
> We should keep in mind that for many extension developers it's probably ok
> to create a SF, GoogleCode or whatever project to host the extension code
> and the binary. But i believe that there are also many developers who simply
> want to put there macro collection in an extension container with the
> necessary meta data and want share it with others. Means they simply want to
> upload it for broader availability without creating their own project or the
> necessity to have their own webspace for hosting the binary extension.

The SourceForge proposed solution would support this in exactly the
way the current system does, see below.

> And i think this is even more important for templates. People create a nice
> template and would ideally be able to upload it directly from the office. Ok
> for upload we would need some kind of registration and authentication to do
> that. But that would be very convenient for users.
> I can think about a similar mechanism (in the future) to package Basic
> libraries with the meta data into an extension and upload it also directly
> from the office.
> I think for such a service we can require the Apache license and can ask for
> it during the necessary registration process and for every upload.
>>> An alternative is to work with a third party willing to help. I've
>>> copied below the text of a mail outlining the SF proposal. You will
>>> note that they are keen to ensure that we don't get locked into the SF
>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>> services is to avoid exposing us to unmanageable risk.
>> This doesn't necessarily need to be an either/or decision.  We could
>> decide to host the canonical directory of extensions/templates, and SF
>> hold host a prominent repository of some of the actual extensions.
>> We also need to get out of the mindset of there being only one
>> extension repository, or even one extension directory, and instead
>> think of a federated approach.  Remember, in an ecosystem with
>> downstream consumers and enterprise deployments,  there will typically
>> be internal-only corporate repositories as well as distro-specific
>> ones, as well as possible directories and repositories from AOO (ones
>> that are project releases under ALv2).  So I'd recommend we think of
>> the problem as being more about protocols and formats for describing
>> and advertising (from a web services perspective) extensions.  On top
>> of that an ecosystem of repositories and directories would emerge.
> i think the current format supports (maybe with minor tweaks) all the
> described scenarios and it should be possible support multiple repos.
> Without checking the code I assume that we have to change the UI and make it
> possible to add further repos to the default. Or allow a list of repos.
>> So:
>> Short term -- stabilize what we have.  Whether at Apache or SF, I
>> offer no opinion.
>> Long term -- take the federated approach.  In this approach we will
>> want a host for the non-ALv2 extensions, so SF's offer makes sense
>> there.
> +1 for short and long term.

First, what we're proposing in the short term is to migrate and
stabilize the current drupal instance using the Secure
Project Web infrastructure.   This would give selected members of the
team SSH access to the server space where it's hosted, and full access
to both the code and database content.

We would help update the code to sync the uploaded files into our
global mirror network, and have downloads go through there to aleviate
pressure on the Drupal infrastucture and give people local download
mirrors for all the extensions and templates.

Middle term we would love to work with you to have this site become
the center of a federated extensions community.   We are working on
mirroring and federation tools already, and would love to have this
new extensions site automatically pickup extensions projects created
in an Open Office Extensions neighborhood on, and make
it trivial to register projects hosted at Google Code, and Github for
incision and automatic updates as well.

We have been working to make projects on the new Sourceforge platform
( more flexible, so if
extensions/template authors want only to track issues, or just to have
a forum, but don't want or need SVN or other version control support,
we already support that kind of project setup.

>> Maybe the short-term offer from them for stabilization could migrate,
>> over time, for them to be a core repository in the eventual federated
>> approach?
> I agree and we should take also into account the promotion opportunities via
> SF that sounds interesting for me as well.

We're open to find ways to collaborate, included the possibility to
help you to find more developers/contributors.


> Juergen
This e- mail message is intended only for the named recipient(s) above. It may contain confidential
and privileged information. If you are not the intended recipient you are hereby notified
that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately notify the sender
by replying to this e-mail and delete the message and any attachment(s) from your system.
Thank you.

View raw message