openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Proposed short term goals
Date Mon, 13 Jun 2011 19:31:12 GMT
I would suggest waiting a few more hours before proceeding
with this to give people time to subscribe.  Also I'm not
sure gating on infra migration is the best strategy to start
off with.  AIUI Oracle is willing to host the domain throughout
the incubation period, which will provide us with many months
to facilitate a smooth transition.

My primary concern at this point is in getting the codebase
into subversion, as pretty much nothing can happen until
that is underway.  I don't believe that's gating on a grant
or anything else from Oracle, all we need to get going is
an svn dumpfile to load.  (Doing the license header migration
will require an appropriate grant, but that can be done at
any time prior to a release).  If it's as big as I expect it to
be infra may postpone the load until the weekend in order
to minimise the downtime impact on the rest of the ASF.

----- Original Message ----
> From: "" <>
> To:
> Sent: Mon, June 13, 2011 3:07:04 PM
> Subject: Proposed short term goals
> At a very high level view, I think we want to set a handful of short term 
> goals, generally around transitioning the project from the Oracle 
> infrastructure to Apache infrastructure. 
> We have other goals, as  well, which are defined for us by Apache, 
> necessary to graduate from a  Podling:
> But  we need to do the basic transition.   It is moving day for OpenOffice! 
>    We need to pack everything from that we want to keep and 
> bring it over to Apache.
> Although we are not obligated to do things  exactly how they were done 
> before in, it seems that the  nature of the project is that 
> we'll have some clearly distinguished  functional subgroups within the 
> project, including:
> 1) Development,  including release management
> 2) Translation/Localization
> 3) Documentation,  both in-product and on-website
> 4) User support, including user forums
> 5)  Marketing
> (Are there any others?  I may be missing  something.)
> I think it would be great if the Committers sort themselves  up for one or 
> more of these functions and help drive the project to some  short-term 
> goals.  Maybe each function has its own email list? (dev,  translation, 
> doc, support, marketing)  Plus a "general" list for  cross-cutting 
> discussions?
>  ===>  Could we get a wiki for the  Podling, as well as the above 
> per-function mailing lists, so we can work on  planning?  I think tossing 
> 90 of us on a single dev list is  non-optimal.
> For example, the Development team should probably focus  on  get the code 
> to build on Windows, Linux and Mac.   As was  noted in the proposal 
> discussion, we believe that Oracle's original SGA will  need to be 
> supplemented by additional contributions in order to get to a  successful 
> build.   We should note other things that appear missing,  like CWS, 
> plugins, etc., as well.  But let's concentrate on the  critical goal of 
> getting to a successful build of the contributed code on  the three major 
> platforms. 
> Translation team might concentrate on  working with Apache Infrastructure 
> team to get a Pootle server set up on and  ensure that Oracle has 
> contributed all translation files.
> Ditto for  documentation and support.  We need to find out what needs to be 
> packed  up, and find a place for it on the new Apache infrastructure.  This 
> includes product-resources, i.e., things that get included in the released 
> install image, but also user-facing web content and project-facing web 
> content.
> Marketing probably wants to work on the trademark and logo  related issues.
> In order to remain coordinated, I'd also suggest that  each team sketch out 
> a plan, maybe on a wiki, for what substeps are needed  to achieve these 
> initial goals.
> Does this make sense?  We need  to get to a point where Oracle can hand 
> over the DNS entries for to Apache shut off their servers, 
> and have continuity of all  important project and user systems running on 
> the Apache  infrastructure.  And by continuity, the ideal situation would 
> be  continuity at the level of a link as well, e.g., an external link to an 
> web site would remain useful after the transition, although 
> it might be redirected.
> -Rob

View raw message