Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAK2iWdSN+g81MnCi8KRkr0C=D=KkdcnD8-MM2Ra8PtPT2cvQZA@mail.gmail.com>
References: 
 <CAK2iWdT8WU9AJLZR_GddwOqgd7NS3ZPegA6wT9WnEWjU376Fjw@mail.gmail.com>
	<CAP-ksohSPgBoBQ00bWVNf2LipSSE-uD2igR5eeFms3xexuio2A@mail.gmail.com>
	<CAK2iWdSN+g81MnCi8KRkr0C=D=KkdcnD8-MM2Ra8PtPT2cvQZA@mail.gmail.com>
Date: Wed, 28 Nov 2012 09:22:52 -0500
Message-ID: 
 <CAP-ksojHYFiWtbT4NYNQd+bdqjS7+poD=ZvAzRcyf7TzTJ9-KA@mail.gmail.com>
Subject: Re: L10n tools is no longer needed.
From: Rob Weir <robweir@apache.org>
To: dev@openoffice.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 28, 2012 at 9:09 AM, janI <jani@apache.org> wrote:
> On 28 November 2012 14:28, Rob Weir <robweir@apache.org> wrote:
>
>> On Wed, Nov 28, 2012 at 4:07 AM, janI <jani@apache.org> wrote:
>> > Thanks to an e-mail from Andrew, I have become aware that LO has
>> finalized
>> > a new tool set:
>> >
>> > http://libreoffice.hu/2012/11/27/featurekillsdf-branch-merged/
>> >
>> > I have had a look, and the tool does with a few exceptions, what genLang
>> > was supposed to do. There are no reason to make parallel developments so
>> > the l10n development has been stopped.
>> >
>>
>> This is great new.  One less piece of code we need to write and maintain.
>>
>> Remember, our license restriction is for code that we publish, the
>> mandatory *runtime* dependencies that we include in our source
>> packages when we release.  These need to be Apache License.  But we
>> have almost unrestricted ability to have other *build-time*
>> dependencies. Consider:  on Windows we require Visual C++ to build.
>> This is not even open source.  On Linux we use many GNU text
>> utilities, and gcc.
>>
>
>> So I'd recommend this:  Ignore for the moment that some LO
>> *individuals* are antagonistic.  Assume good will.  Send a note to
>> their public mailing list saying that you see the great work they've
>> done with these conversion tools and are looking to adopt them for
>> AOO.  Say that you might have some patches to contribute back.  Say
>> that preserving these utilities as independently buildable parts of LO
>> would be very useful for others who might want to reuse them and help
>> maintain them.
>>
>
> Thanks for your recommendation I agree with what you say, and then we are
> back to my other theme...I could easily join the LO mailing list, even be a
> committer. But please understand my openSource life is about
> producing/maintaining code for the infrastructure (build/translate etc), so
> that other developers can implement fantastic programs, not thinking too
> much about multiple dev mailing lists etc.
>

Right.  So how well a project can modularize its concerns, so
volunteers can work on areas of interest without needing to "drink
from the firehose" is important.  Ideally someone can work on these
conversion tools without needing to download and build all of
LibreOffice, for example.  If this is true, then you can direct your
personal time and energy more optimally.


> At this point l10n is not a development project, but is more a task for the
> gbuild project to integrate the existing tools.
>
>
>>
>> If you get a favorable response, then great.  We're collaborating.  If
>> not, then we can fork the utilities and put them on Google Code (a
>> section we call ApacheExtras).  We'd let them know about that and
>> welcome them to check that repository occasionally to grab our
>> enhancements, which we encourage.
>>
> Put things on Google code is really something I would never do, that is to
> me a factor too political, in that case I would submit the changes to LO
> directly. But I have a feeling (putting in politely) that the collaborating
> issue belongs at quite a higher level than where I am.
>

I wouldn't do Google Code for political reasons.  I'd do it only for
technical considerations, e.g., if it is impractical to use these
tools from the LO tree without bringing in 200 MB of extraneous
dependencies.  If that was the case then making a cleaner,
self-contained build of these tools might be warranted.  But that
would only be a last resort.

And if anyone feels that they are not empowered, as individuals, to
collaborate with LibreOffice on areas of mutual interest, then we're
doing something wrong.  This is not above anyone's pay grade.  In fact
we already have a few contributors who contribute code to both
projects.  And we have several LO contributors who have agreed to make
their enhancements available to AOO as well, under ALv2.

-Rob
> In other words, start with an optimistic, pro-collaboration, "yes we
>> can" attitude.  Work openly and publicly.  If we're disappointed it
>> will be clear that it was not AOO that was frustrating collaboration.
>>
>> -Rob
>>
>> > It would be nice to add the missing features to the LO tool and give it
>> to
>> > both LO and AOO, but that requires skills where development is the least
>> > part.
>> >
>> > When finishing a project I like to look back and see which lessons can be
>> > learned...in my case there are many, but one is standing out:
>> >
>> > Can it really be true that we all need to keep an eye on both the LO
>> > developer activities as well as the AOO activities. At the moment we
>> waste
>> > the very limited resources:
>> > - We solve a lot of the same bugs (I hope some developers, solve the bug
>> > once, and post it on both LO/AOO)
>> > - We test a lot the same
>> > - We translate to a high degree the same text (we call for volunteer
>> > translators, but why not use the texts already translated).
>> >
>> > Would it not be a wonderful world, if openSource was truly open and we
>> > could share instead of discussing whether the header (license) in the
>> files
>> > is blue or red.
>> >
>> > Our common user base does in general not care, or maybe even understand
>> the
>> > differences between a red or blue license, they care about a well
>> > functioning product that are steadily getting new features, so why are we
>> > as volunteers not trying harder to reach that goal.
>> >
>> > If I were PMC I would have one high priority on my list:
>> > - How to get a common code base between LO and AOO, with possibility to
>> > differentiate, so resources can be shared instead of effort duplicated.
>> > - How to share bug fixes, information about new developments etc.
>> >
>> > It is soon Christmas so it allowed to wish....my wish this year will be
>> > that some of our funding is spent on, getting key people for LO and AOO
>> > together. Lock them up in a room with a big pizza, tell them the door
>> will
>> > be unlocked when they have agreed on how to slice the pizza, instead of
>> > make two mini pizzas.
>> >
>> > Jan.
>>