On 1/3/12 5:25 PM, Rob Weir wrote:
On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
<[email protected]> 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:
http://markmail.org/message/sm57zvd5gnblxpo6
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.
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.
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.
Juergen
