2011/8/15 Jürgen Schmidt <[email protected]>: > On Sun, Aug 14, 2011 at 8:28 PM, Rob Weir <[email protected]> wrote: > >> On Sun, Aug 14, 2011 at 2:06 PM, drew <[email protected]> wrote: >> > On Sun, 2011-08-14 at 13:37 -0400, Rob Weir wrote: >> >> On Sun, Aug 14, 2011 at 1:06 PM, drew <[email protected]> wrote: >> >> > [from out of left field] >> >> > Would members consider transferring ownership of the current >> repository >> >> > hosted on the OSUOSL server to a third party, perhaps created >> >> > specifically to take this over, and then working with them to create >> the >> >> > indirect reference site under the AOO project, filtering out >> >> > un-acceptably licensed items as a way to achieving option #2. This >> would >> >> > move the entire repository without needing to locate individual >> authors. >> >> > >> >> >> >> I don't see how we can claim ownership of the content on the OSUOSL >> >> server. >> > >> > Hi Rob, >> > >> > Well, I'm not at all sure I agree with that, what exactly happened then >> > when the Sun brand came off the site and the Oracle brand went up, that >> > was window dressing with regards to the site name - Oracle could not of >> > moved the site to xxx.oracleoffice.org even if they also maintained a >> > live redirect of the old address? >> > >> >> Generally, you may do whatever the owner of the copyright allows you >> to do. The trick is to determine what the copyright owner allows you. >> With the lax attention to this detail by the OOo community over the >> years, this important fact is hard to determine in many cases. This >> is something we should not seek to repeat at Apache. >> >> Not just with extensions, but throughout the project we are going to find a >> mix: >> >> 1) Things we are certain we have rights to use, e.g., things in the >> SGA, under Apache 2.0, things with clear provenance >> >> 2) Things that we are certain we do not have rights to use, e.g., GPL >> components. >> >> 3) Things that we cannot determine whether or not we have rights to use. >> >> We're going to spend most of our time on that 3rd category. But once >> we've done that, and documented it, then we've improved the project >> considerably and made it easier for us and others going forward. But >> it might require that we eliminate some contributions that were >> otherwise excellent, because we cannot confirm our rights to use them. >> >> >> It was not part of the Oracle SGA, as far as I know. So it >> >> is not ours to give to a 3rd party. >> >> >> >> But if a 3rd party steps forward and is willing to navigate the >> >> licenses and figure out way to host them all, then I'd wish them the >> >> best of luck. >> >> >> >> The main technical things we need to coordinate are: >> >> >> >> 1) How are submissions made to the catalog >> > i would prefer a web form as in the existing repo > > >> >> >> >> 2) How is the catalog queried? >> >> >> >> 3) How are extension updates propagated? >> >> >> > The existing mechanism works quite well > > See also > http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Online_Update_of_Extensions > and related sub chapters > > >> >> 4) Do we want a single catalog, in the style of Firefox plugins, or >> >> allow multiple catalogs, perhaps filtered by support category or >> >> license, like Ubuntu? >> > i would prefer a multi repo (catalog) approach directly from the office to > allow maximal flexibility > > >> >> >> >> 5) What do we need to do to ensure a clean programmatic interface to >> >> the catalog (a RESTful service) as well as a good end-user UI? >> >> >> >> 6) Is there a way we can manage, with sufficient user data protection >> >> provisions, some sort of recommendation engine, where extensions are >> >> recommended either based on user actions, or based on ratings and >> >> similarities to other users (collaborative filtering)? >> >> >> >> 7) Is there anything we can do to allow the user to interact with >> >> extensions (browse, sort, filter, download, rate, update, etc.) >> >> entirely within OOo editors? >> > definitely, > update is already possible but browsing extensions directly form the office > is a long wanted feature. And not only for extensions. A new designed > template dialog that allows browsing a template repo, download of templates > for offline use, allows the upload in this repo (under Apache 2.0), > > But for both extensions and templates it is important that we make it > configurable. Means it should be possible to disable it or to limit it to a > specific repo only. This is important for enterprises with more > restrictions. But it allows to manage a local repo for company wide used > extensions and templates. A single place for maintenance (updates, > bugifxes) of these extensions/templates. >
That is an excellent point. The ability to define a corporate extension catalog would be an important enterprise feature. If could almost be like Atom or RSS -- items and feeds. > >> >> >> >> So in general, I think this is an opportunity to do more than just >> >> re-host the existing extensions site. It is an opportunity to rethink >> >> how users and extensions authors could interact. >> > >> > I agree with much of that >> > - I guess I would opt here to pull us back from either my >> > out-of-left-field idea, or the perfect solution for the moment. >> > >> > Just hit the templates site and it's back, I would rather we ask the >> > current admin about what, if any, maintenance is needing done on the >> > site, and then we should offer, if it would help, to try and find some >> > volunteer help to get that done, asap. >> > >> >> That sounds like a wonderful near-term solution. >> > > indeed and it would give us some more time to think about a good solution > > >> >> It is a matter of perspective: >> >> 1) Is the extensions site an official service provided by the project? >> >> or >> >> 2) Is the extensions site a 3rd party service for the benefit of the >> larger community? >> > > i would like to see both. > > 1) an official and default Apache extension repository (under Apache 2.0) > > and 2) a well defined interface that allow others to run a 3rd party > repository. > > A good and working extension infrastructure and a better integration in the > office directly is a key element from my point of view for a working > eco-system. > > Juergen > > > >> >> >> I think either one is fine, but each has its own constraints. With >> #1, we are then under Apache rules for license, etc. But we can use >> Apache hardware. >> >> And for #2, we are free to link to the external service from our >> website, but we should have a disclaimer, along the lines of what >> Apache Subversion has for its binary releases: >> >> "The Apache Subversion project does not officially endorse or maintain >> any binary packages of the Subversion software. However, volunteers >> have created binary packages for different distributions and >> platforms, and as a convenience, we maintain a list of links to them >> here." >> >> >> > While not to lose focus on working those longer term ideas. >> > >> > Best wishes, >> > >> > //drew >> > >> > >> >
