On 28 November 2012 15:22, Rob Weir <robw...@apache.org> wrote: > On Wed, Nov 28, 2012 at 9:09 AM, janI <j...@apache.org> wrote: > > On 28 November 2012 14:28, Rob Weir <robw...@apache.org> wrote: > > > >> On Wed, Nov 28, 2012 at 4:07 AM, janI <j...@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 youd 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. >
I hope we can agree that since the code is developed and freely available, then there is no reason to develop it again. Getting the tool is quite easy, storing the tool in AOO SVN (even as external) is not a development problem but I guess could be a long discussion item (I just think about the response about my proposal to store setup changes to our own mwiki data in SVN). But no need to discuss the matter further in public, that is no good for anybody. > > > 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. > >> >
