From ooo-dev-return-20160-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Fri Jun 1 23:10:10 2012 Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7BE83C127 for ; Fri, 1 Jun 2012 23:10:10 +0000 (UTC) Received: (qmail 65487 invoked by uid 500); 1 Jun 2012 23:10:09 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 65410 invoked by uid 500); 1 Jun 2012 23:10:09 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 65402 invoked by uid 99); 1 Jun 2012 23:10:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2012 23:10:09 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rgardler@opendirective.com designates 209.85.161.175 as permitted sender) Received: from [209.85.161.175] (HELO mail-gg0-f175.google.com) (209.85.161.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2012 23:10:02 +0000 Received: by ggnp4 with SMTP id p4so2256502ggn.6 for ; Fri, 01 Jun 2012 16:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opendirective.com; s=opendirective; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=Y7qhYUyC3fjYHecVqLkl1CwN50X/wAjIQLxdPF14wA8=; b=HeS2cwJLwiUUUQon2zrBkGBW8M4tt95yVU5O/jwzGSgF5+EkCuvygvWWeFjcVbvsJt 3lzIdrTRcJY4M5xWV7uzr5dP0QnSwS7lgjf83lWYKJo/TnTZjFYCS17vlytX5TYFfF0x HPf3TAxThHyw2h4EOjR3o7WR0vCceQODiMedY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=Y7qhYUyC3fjYHecVqLkl1CwN50X/wAjIQLxdPF14wA8=; b=ZU+6NN4iCaz52mhfTgkpbDfko7I7rZ/aXcCe5ShICaavpEzHGtZNBkbTRJUWJJ2HM9 YZwO/kHR9V3ydC9lcESbgpy6+ayVjhfoW/RQNHJHNJTFoiGPKnJ2ZUZAF1ktjk5urDdI yrJQhUpTCtF8F1HQu0jJzLTaoevQRS638oYFPfI0IrWAC2DRkl6ivBu49XggBow65cCU grbE7sZMmq+GQtkLZ9HCsRmkbuNxoOB4TO4XJHThpEpz0t6H+VojR5T+FOX14nb0QhSY RLUQxSP90Lvj6Q/1Ky8RNV6dc8dmD5/eBB0q3W8m3GdMiLCI6Tkzb5TtrHDqxUcVhoan TOrg== Received: by 10.50.100.169 with SMTP id ez9mr3053608igb.44.1338592181237; Fri, 01 Jun 2012 16:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.112.5 with HTTP; Fri, 1 Jun 2012 16:09:01 -0700 (PDT) X-Originating-IP: [81.153.28.221] In-Reply-To: <4FC894F5.9070900@googlemail.com> References: <1338428718.42092.YahooMailClassic@web113506.mail.gq1.yahoo.com> <4FC75BEA.1070808@a-w-f.de> <4FC790BE.3050008@googlemail.com> <4FC79BA7.1060707@apache.org> <4FC8826B.2090600@googlemail.com> <4FC894F5.9070900@googlemail.com> From: Ross Gardler Date: Sat, 2 Jun 2012 00:09:01 +0100 Message-ID: Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process) To: ooo-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmQ2YBzC7nXmAG1b0hpXBE10YMvFzRgS8+hVMAQWEaZJW8YHq+30A/3zK1InGHSBj8hWvxS Just bringing this item back to the top. Nobody has linked to a policy that allows this or disallows it yet. However, Pedro has indicated he doesn't object to this specific case. Can we consider this one done? If so that is good progress (thank you Jurgen for making consensus possible on one specific case). Lets move onto the next one. Pedro raised a concern about a specific case and, if I'm following right there isn't consenus on that one (I wouldn't be surprised if I'm not following right since I'm tired of reading the arguments that go round in circles and stopped as soon as it descended again into non-specific cases). Can we have an equally detailed and clear description about the case Pedro highlights? We only need the facts about the problem being solved and the current solution, not the arguments for/against. Pedro, I suggest it's your turn since Jurgen started the ball rolling, Rob can be up next (sorry to sound like a school teacher, please think of me as a conductor not a school teacher - I'm not trying to patronise, it's just it's very late here and I still have a client deliverable that AOO has stood in the way of for the last two days). Once we have the facts laid out nice and cleanly lets seek pointers to policy that allows or disallows the solution in place. If pointers are not possible lets take the specific case to the IPMC for clarification. Ross On 1 June 2012 11:09, J=FCrgen Schmidt wrote: > Hi, > > sorry for top posting but I followed Ross advice and will give a > concrete example. > > Hunspell -> MPL + LGPL > > - we use currently version 1.2.9 and compile the source in our build env > on demand when the correct configure switch is used > > - we apply 4 or in case of mingw 5 patch files (depends on the mechanism > that is used in our build env generally for this kind of things) > > 3 of these patch files contains minor changes used/necessary for our > build env. > > For example hunspell-solaris.patch: > ### > --- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx =A0 =A0 2010-02-27 > 23:42:05.000000000 +0000 > +++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx =A0 =A02010-02-27 > 23:43:02.000000000 +0000 > @@ -10,6 +10,9 @@ > =A0#include "hunspell.hxx" > =A0#include "csutil.hxx" > > +// switch off iconv support for tests (fixing Solaris problems) > +#undef HAVE_ICONV > + > =A0#ifndef HUNSPELL_EXTRA > =A0#define suggest_auto suggest > =A0#endif > ### > > One patch apply a back port patch for an important issue that is fixed > in a newer version. Don't ask me why we haven't upgraded the version > already. But that is as I mentioned before on our plan. > > hunspell-stackmash.patch > ### > --- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx =A0 =A0 =A0 2010-03-04 > 10:25:06.000000000 +0000 > +++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04 > 10:25:38.000000000 +0000 > @@ -1665,7 +1665,7 @@ > =A0 if (!q2) return 0; // bad XML input > =A0 if (check_xml_par(q, "type=3D", "analyze")) { > =A0 =A0 =A0 int n =3D 0, s =3D 0; > - =A0 =A0 =A0if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =3D > analyze(slst, cw); > + =A0 =A0 =A0if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n = =3D > analyze(slst, cw); > =A0 =A0 =A0 if (n =3D=3D 0) return 0; > =A0 =A0 =A0 // convert the result to ana1ana2 = format > =A0 =A0 =A0 for (int i =3D 0; i < n; i++) s+=3D strlen((*slst)[i]); > @@ -1686,13 +1686,13 @@ > =A0 =A0 =A0 (*slst)[0] =3D r; > =A0 =A0 =A0 return 1; > =A0 } else if (check_xml_par(q, "type=3D", "stem")) { > - =A0 =A0 =A0if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return > stem(slst, cw); > + =A0 =A0 =A0if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) re= turn > stem(slst, cw); > =A0 } else if (check_xml_par(q, "type=3D", "generate")) { > - =A0 =A0 =A0int n =3D get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN); > + =A0 =A0 =A0int n =3D get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - = 1); > =A0 =A0 =A0 if (n =3D=3D 0) return 0; > =A0 =A0 =A0 char * q3 =3D strstr(q2 + 1, " =A0 =A0 =A0 if (q3) { > - =A0 =A0 =A0 =A0if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) { > + =A0 =A0 =A0 =A0if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1= )) { > =A0 =A0 =A0 =A0 =A0 =A0 return generate(slst, cw, cw2); > =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 } else { > ### > > This fix is fixed upstream in version 1.2.11, see > http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell= /hunspell.cxx?r1=3D1.8&r2=3D1.9 > > > That means with our further ongoing improvements in this area we get rid > of this patch and have only minor patches for our build env. > > Building these libs on demand in our build env is for convenience. > Otherwise we would have to put them somewhere else, have to duplicate > the build env or would need to build them with our build env and use the > binary libraries from there. That would mean a further huge burden to > make the development for AOO more complicate. > > I hope this helps > > Juergen > > > On 6/1/12 11:07 AM, Ross Gardler wrote: >> On 1 June 2012 09:50, J=FCrgen Schmidt wrot= e: >>> On 6/1/12 9:47 AM, Ross Gardler wrote: >>>> Sent from my mobile device, please forgive errors and brevity. >>>> On May 31, 2012 5:26 PM, "Pedro Giffuni" wrote: >>>>> >> >> ... >> >>>>> I admit this is very clear. I don't expect such development to be >>>>> a requirement for graduation but the transitory situation of a source >>>>> release that depends on carrying category-B tarballs in SVN now is >>>>> not really acceptable. >>>> >>>> I do expect this to be sorted out before graduation. >>> >>> it is addressed already >>> >>>> That might be as simple as getting clarity on the policy, it might be = more >>>> than that. However, as a mentor I am uncertain about the practice adop= ted >>>> here and as such will not encourage the IPMC to vote for graduation un= til >>>> someone in the PPMC gets clarity. >>> >>> what do you expect? >> >> Someone needs to take out all the rhetoric and abstract concepts. Pick >> any one of the cat-b cases and describe *exactly* how it is addressed >> in that case and *exactly* how this conforms to documented ASF >> policies. >> >> Once we have clarity on the first case we can ask whether any of the >> other cases are different and then examine those. >> >>> Should we remove all this dependencies and make AOO more or less >>> unusable or better uninteresting for real usage? >> >> I am making no comment on what the technical solution is. >> >> I want to see consensus. Consensus cannot be gained by shouting at one >> another about vague examples. I want concrete examples on a case by >> case basis until nobody is objecting or until the issues can be >> clearly communicated to either the IPMC or legal@ so that a >> clarification of ASF policy can be made. >> >>> Anyway I think we tried everything to address this and we still work on >>> improvements step by step. If that is not enough for graduation I would >>> feel very unsatisfied. >> >> It is, and always has been, a condition of graduation that the IP >> situation in the project conforms to ASF policies. There is a question >> about these tarballs and it must be resolved before graduation. >> >> Ross > --=20 Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com