incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 23:09:01 GMT
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ürgen Schmidt <jogischmidt@googlemail.com> 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     2010-02-27
> 23:42:05.000000000 +0000
> +++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx    2010-02-27
> 23:43:02.000000000 +0000
> @@ -10,6 +10,9 @@
>  #include "hunspell.hxx"
>  #include "csutil.hxx"
>
> +// switch off iconv support for tests (fixing Solaris problems)
> +#undef HAVE_ICONV
> +
>  #ifndef HUNSPELL_EXTRA
>  #define suggest_auto suggest
>  #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       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 @@
>   if (!q2) return 0; // bad XML input
>   if (check_xml_par(q, "type=", "analyze")) {
>       int n = 0, s = 0;
> -      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
> analyze(slst, cw);
> +      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
> analyze(slst, cw);
>       if (n == 0) return 0;
>       // convert the result to <code><a>ana1</a><a>ana2</a></code>
format
>       for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
> @@ -1686,13 +1686,13 @@
>       (*slst)[0] = r;
>       return 1;
>   } else if (check_xml_par(q, "type=", "stem")) {
> -      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
> stem(slst, cw);
> +      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
> stem(slst, cw);
>   } else if (check_xml_par(q, "type=", "generate")) {
> -      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
> +      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
>       if (n == 0) return 0;
>       char * q3 = strstr(q2 + 1, "<word");
>       if (q3) {
> -        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
> +        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
>             return generate(slst, cw, cw2);
>         }
>       } 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=1.8&r2=1.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ürgen Schmidt <jogischmidt@googlemail.com> wrote:
>>> 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" <pfg@apache.org> 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 adopted
>>>> here and as such will not encourage the IPMC to vote for graduation until
>>>> 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
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Mime
View raw message