incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 16:55:49 GMT
Hi Jürguen;

On 06/01/12 05:09, Jürgen Schmidt wrote:
> Hi,
>
> sorry for top posting but I followed Ross advice and will give a
> concrete example.
>
> Hunspell ->  MPL + LGPL
Hunspell illustrates a case that I would consider unsupported but
valid for redistribution.

My opinion on the MPL+ patches is as follows.


-I don't see a problem patching the MPL sources for two reasons:
1) We don't do this by default, the patches are only there for
convenience to external packagers. It must be made clear they
are unsupported though.
2) The patches are under ALv2.

I do think it would be consistent with (1) to disable category-B in the
buildbots: The category-B dependencies as they are right now
(built from source and patched) are unsupported. We can officially
support them only if we use binaries (I am thinking of Java bytecode
and fonts).

I would like now to point out another case that points out a
real issue:

We are using Seamonkey version 1.1.14 and we are patching it.
Version 1.1.14 is unsupported upstream and the Mozilla Foundation
doesn't carry it anymore. For all purposes it seems like we have forked
this package and can be considered "upstream".

We are not allowed to distribute MPL code at all, and even if we just
mirror it for convenience to our users, like in this case, we will always
be exposed to becoming the mainstream distributors of forked code.

Pedro.




> - 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


Mime
View raw message