incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Releasing OOo 3.4 on the old infrastructure
Date Mon, 04 Jul 2011 13:11:09 GMT
Point of reference:  the subversion project used non-ASF infrastructure
to conduct releases that would've been blocked by ASF policy on licensing

had they used our mirror system.  It is certainly possible to do the
same sort of thing with ooo for an interim solution, until the codebase
has been "cleaned up" to meet with ASF policy.

----- Original Message ----
> From: Eike Rathke <>
> To:
> Sent: Mon, July 4, 2011 9:06:52 AM
> Subject: Re: Releasing OOo 3.4 on the old infrastructure
> Hi Andrea,
> On Sunday, 2011-07-03 18:27:09 +0200, Andrea Pescetti  wrote:
> > 2) 3.4 is mostly ready. I built the  latest code from hg
> >    a couple weeks ago and I've regularly  used it so far. The quality is
> >    good and there is no risk of  damaging the OOo reputation. All
> >    release stoppers are bugs  that will have to be fixed anyway, and
> >    fixing them later  will require the same amount of time.
> There are a couple of CWSs targeted  to OOo3.4 that address release
> critical bugs and are not integrated to the  OOO340 code line yet. Many
> of them have status nominated, some not. A release  should include them,
> problem is that on the old OOo infrastructure work can't  happen as
> a) we don't know if that infrastructure will be available  sufficiently
>    long enough for all release relevant work
> b)  releases with the brand name will be bound to the
>     trademark and can only be done by the trademark owner, IMHO (IANAL)
> On  the other hand, a release can't be done quickly on Apache, be it for
> the  incubator status of this project or merely because of technical
> reasons that  we won't get a releasable status of the code base in time
> as we won't have  the original OOO340 code base under ASL.
> I would be delighted if someone  pointed out a way we could solve that
> dilemma, but I fear we're stuck at the  moment.
>   Eike
> -- 
>  PGP/OpenPGP/GnuPG encrypted mail  preferred in all private communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41  0149 0DB3  9E96 2F1A D073 293C 05FD

View raw message