On May 29, 2012, at 11:41 PM, Jürgen Schmidt wrote: > Hi, > > sorry for top posting but I would like to suggest that we come back to Rob's > initial question. > > Simplified: > Should we start graduation now?
Yes, as long as we understand that the following is an evolving issue regardless of whether we are a TLP or part of the Incubator. The IPMC will certainly tell us if it is a blocker to graduation. I don't think it is, but someone else will differ. The IPMC is as big as this PPMC, there is lots of room for difference. > Pedro's concerns are valid. On the other hand the question is what really > changed when we move the source tarballs to a different place? > > I think Rob tried to explain that there is no real difference. And we don't > include any category-b source in our source release package. > > Well I would support both solutions for now but I am in favor to have a long > term solution to replace category-b libraries where possible as Pedro has > already pointed out for some libraries. > > But we should keep in mind that this changes are not trivial and the work > have to be done by somebody. We analyzed for example the address book > replacement and postponed it because it is a huge task and potentially we can > replace it later by switching to native platform support on the different > systems... > > Some patches for libraries can't be up-streamed because the maintainer is not > interested in patches that introduce the stlport for example. The problems > are sometimes very simply. That means we have first to eliminate the stlport > dependencies and use the compiler stl and can drop further dependencies in a > second step and can use binary packages directly. I could list more examples > and I don't think that we ignore this items. We have thought about it very > careful and have done what was possible in the release time frame. It might be worth bringing this question to general@i.a.o and pre-flight opinions. It helped with the release, it can't hurt graduation. Regards, Dave > > > Juergen > > > > On 5/30/12 4:21 AM, Pedro Giffuni wrote: >> Hi; >> >> --- Mar 29/5/12, sebb<seb...@gmail.com> ha scritto: >> >> ... >>>> >>>> This is admittedly a stop gap solution to comply >>>> better with the Apache policies, the real fix would >>>> be to work collectively on replacing the code that >>>> can be replaced: >>> >>> Alternatively, it is possible to include cat B [1] >>> dependencies in binary form. >> >> We do this for FreeBSD and it works great. >> >>> Is there any need to include the source? >>> >> No. The real reason why OOo historically has carried >> the sources for everything is/was that previously the >> GPL forced developers to make the sources available. >> >> The issue is the multiplatform support. For builders >> on platforms like Windows it's not really fun to go >> looking for the different dependencies. This said, >> for Java stuff it is perfectly OK to include only >> binaries (except for our old saxon-B, which is >> deprecated upstream so we have to carry the sources >> somewhere) >> >> >>> [1] http://www.apache.org/legal/resolved.html#category-b >>> >> While [1] is the official document, I find the original >> draft policy explains things much better: >> >> http://www.apache.org/legal/3party.html >> >> cheers, >> >> Pedro. >
