RE: [E-devel] Apache OpenOffice 4.1.2 locks in Enlightenment 0.21.99.21605
[BCC to AOO dev list] Please remove dev@openoffice.apache.org from these messages. The discussion seems to have little to do with Apache OpenOffice and there appears to be nothing that the project can contribute with respect to this issue. If that is not the case, please open a bugzilla issue about it on the Apache OpenOffice project. - Dennis > -Original Message- > From: Carsten Haitzler (The Rasterman) [mailto:ras...@rasterman.com] > Sent: Tuesday, August 30, 2016 16:45 > To: Jose R R > Cc: Enlightenment developer list de...@lists.sourceforge.net>; dev > Subject: Re: [E-devel] Apache OpenOffice 4.1.2 locks in Enlightenment > 0.21.99.21605 > > On Tue, 30 Aug 2016 04:22:00 -0700 Jose R R said: > > > Thanks for replying. > > > > On Sun, Aug 28, 2016 at 11:27 PM, Carsten Haitzler > > > wrote: > > > On Sat, 27 Aug 2016 03:42:52 -0700 Jose R R > said: > > > > > >> Niltze [Hello], all! > > >> > > >> I've noticed that Enlightenment 0.17.x.y and 0.21.x.y GUI > environment > > >> sometimes becomes locked upon mousing over icons in Apache > OpenOffice > > >> 4.1.2. > > >> > > >> Notwithstanding, when I built Enlightenment 0.19.x.y and 0.20.xy, > the > > >> locking issue disappeared and I thought it was resolved; but then > issue > > >> reappeared once more in Enlightenment 0.21.x.y. I have to CTRL + > ALT and > > >> press F1, F2, etc. to get another shell, login and restart XDM. > > >> > > >> Any feedback would be greatly appreciated. > > > > > > is e stuck - has it crashed? do you get a crashdump? > > E21 must be 'stuck' -- as I can't locate a 'crashdump'. > > > > Please see pic at: > > < > > https://metztli.it/blog/media/blogs/ixiptli/quick- > uploads/p125/e21_apacheoo_issue.png?mtime=1472553272 > > > > > > > > > https://www.enlightenment.org/docs-efl-debug > > I will try this as time avails. Thank you. > > > > > > you can also find if it isnt crashing by forcing a segv and seeing > where > > > the bt says it was stuck: > > > > > > killall -SEGV enlightenment > > I have executed above directive and Recovery option seems useful -- as > > I don't have to restart XDM, thus potentially preserving existing > > sessions and/or data/work; again, please snapshot above and if > > interested for context, post entry: > > < > > https://metztli.it/blog/index.php/ixiptli/eterm-and-enlightenment- > window-manager > > > > > so when you sent a SEGV to enlightenment... after that did you have > ~/.e-crashdump.txt ? because you now FORCED it to crash, thus a > crashdump > should be produced. this may not work if yama ptrace is enabled. > > sudo sysctl -w kernel.yama.ptrace_scope=0 > > > will turn that off. you need gdb installed too. also when compiling e > and efl > you need your CFFLAGS to contain "-g" to enable gdb debug symbols of > course. > > export CFLAGS="-g -O2 -march=native -fvisibility=hidden -ffast-math" > > for example before you compile. > > remember - e APPENDS to the crashdump file every crash, so the most > recent > crash is the last bt set - grep for "pause" to find the crash points. :) > > so crashdump file after this? that'll tell use what's up. hopefully. or > give us > another thing to follow. > > p.s. > > btw - why eterm? eterm is fine and all but its an old old old school > terminal > still using xlib directly etc. terminology is the modern terminal that > uses efl > et. (runs even on OSX too) that has real bells and whistles (videos in > the bg, > inline image display, tabs AND splits etc.)? and it does PROPER > transparency - > no "esetroot" with fake "lets copy parts of the background pixmap into > app > window to make it look transparent but only with a wallpaper". > > > > > > > -- > > > - Codito, ergo sum - "I code, therefore I am" -- > > > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > > > > Best Professional Regards. > > > > -- > > Jose R R > > http://metztli.it > > -- > --- > > Try at no charge http://b2evolution.net for http://OpenShift.com PaaS > > -- > --- > > from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy > way! > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Merge with LibreOffice?
> -Original Message- > From: Απόστολος Συρόπουλος [mailto:asyropoulos...@hotmail.com] > Sent: Saturday, August 6, 2016 12:36 > To: dev@openoffice.apache.org > Subject: ΑΠ: Merge with LibreOffice? > > > >> Greetings, dear AOO community. > >> > >> Please note first that this message is not supposed to be flaimbait > or > >> trolling of any kind. > > > >It is. Have a nice day. > > Well it is not! I am Solaris user and sometime ago I tried to compile > OpenOffice, when > in fact it should compile on Solaris out-of-the-box... I asked the core > developers > to drop support for SunStudio since it assumes one compiles with a > version that > shipped with Solaris 9 (the current version of Solaris is 11 and Solaris > 9 was eoled a > few years ago...) and it does not compile even with recent versions of > SunStudio. > And when I managed to compile everything, I had noticed that OpenOffice > could > not open docx and othe zipped document formats. The people of > LibreOffice > asked me to incorporate my patches to their source tree (I had of course > no > objection). Now LibreOffice compiles just fine under Solaris and there > are packages > for all variants of Solaris including the Open version. In a nutshell, > some people > listen and care about any user while some others just don't give a > dime... > > Regards, > A.S. [orcmid] The Apache OpenOffice project does not have the capacity for what you are able to find elsewhere. As you know, the Apache OpenOffice project has never provided a Solaris distribution, although there were folks who managed to build one themselves. The same goes for OS/2, although OS/2 patches are contributed back upstream. There are probably other efforts that we simply don't know about. The question I am left with is this: If a cousin development provides what you want, why are you not satisfied with that? - Dennis > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Independent Entity to Develop and Further AOO
One can always create an independent entity. It hasn't happened. By now, the odds are clearly that it will not. I suspect that folks who would pursue that avenue do not see a meaningful opportunity. My considered opinion is that the greatest barrier is lack of a meaningful business/operation/funding model. In addition, there is an insufficient supply of developers having the capacity, capability, and will to provide material improvements to Apache OpenOffice. Whatever the pool might be, it is aging and shrinking for many reasons. The affliction that Apache OpenOffice suffers under in that respect also besets any organization set up to support the code, even with paid developers. I also don't think working on Apache OpenOffice is much of a resume builder, since there is no other project like it and probably will never be. There are far easier projects to build an open-source reputation with, ones that build developer skills in areas where there is a growing and future demand. Having suggested this much, I don't think it is meaningful to address how an external entity could "ensure they work on the AOO codebase using the ASF way." If my appraisal is sound, that leaves us with the question about sustainability of the Apache OpenOffice project itself, and what the consequences of unsustainability are. - Dennis > -Original Message- > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Monday, July 11, 2016 14:04 > To: dev@openoffice.apache.org > Subject: RE: Independent Entity to Develop and Further AOO > > There is a bit to discuss about how "The entity should ensure they work > on the AOO codebase using the ASF way" is workable or not. In > particular, no such entity can direct the project at Apache or otherwise > effectively govern it. More about that later. > > There is another option, summarized below. One might also consider this > as a reality check. That is, if that is not feasible, it may be that no > other arrangement is. > > > -Original Message- > > From: Suminda Dharmasena [mailto:sirinath19...@gmail.com] > > Sent: Monday, July 11, 2016 00:23 > > To: market...@openoffice.apache.org; dev@openoffice.apache.org > > Subject: Independent Entity to Develop and Further AOO > > > > Hello, > > > > I am writing to see if the current AOO Dev team would like to create > an > > independent entity which can: > > > >- Do trainings > >- Accept funds and have pay developers > >- Write commercial books / online tutorials with sponsorship > > > > This can be used have paid developers working on the project. Maybe > > initial > > sponsorship can come from an organisation like Redhat, Pivotal or > Micro > > Focus if they are interested. Perhaps companies which used the code > base > > in > > the past like IBM or Oracle. > > > > The entity should ensure they work on the AOO codebase using the ASF > > way. > > > > Suminda > [orcmid] > > AN ALTERNATIVE APPROACH > > Another way to interact and support Apache OpenOffice in terms of > collaborative contributions is as follows. > > 1. Establish a downstream producer, TeamX (for example), that provides > releases of derivative software based on Apache OpenOffice. > > 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the > use of Apache OpenOffice source code. Apache trademark requirements are > satisfied in any use as part of the branding of the downstream product. > > 3. Assumption #2: New code and modifications to the TeamX derivative > are also under ALv2. > > 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs > are contributed back upstream to Apache OpenOffice. Components from > other sources would, of course, be contributed upstream to those > sources. Contributions and joint concerns might lead to use of the > OpenOffice bugzilla as a coordination point. > > 5. Opportunity. The business model, organization, and governance of > TeamX is not of concern to the ASF. > > 6. Opportunity. The Apache Software Foundation requirements beyond > honoring of the ALv2 that govern Apache projects serving the public > interest do not apply, although TeamX could operate in a harmonious > manner. > > 7. Opportunity. So long as there is clear separation and no comingling > in source-code files, TeamX is not constrained from also using code or > components from other projects, such as those using licenses such as the > MPL or, under appropriate conditions, something like LGPL2, with > appropriate honoring of those licenses too. However, to avoid tainting > of upstream source-code contributions back to Apache OpenOffice, there > must be careful management of IP and reliance on code (source or binary) > under non-ALv2 license (and ALv2 code which is not the original work of > TeamX). > > 8. Opportunity. Depending on how close the operation of TeamX releases > remains to that of Apache OpenOffice, especially at the beginning, one > can rely on the Apache
RE: Putting Windows First ( was RE: null)
> -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Wednesday, July 13, 2016 12:57 > To: dev@openoffice.apache.org > Subject: Re: Putting Windows First ( was RE: null) > [ ... ] [orcmid] > I would like to suggest a way of squeezing out from between the rock and > hard place, and getting more developers: > > Separate out the Windows build process. Pick one of the common IDE's, > and create a project file that sets all environment variables for > Windows. Get as close as possible to the step-by-step build instructions > for Windows being: > > Check out the source from SVN. > > Open the project file in $IDE$. [orcmid] I don't think it is necessary to have an IDE commitment. Everything needed to do a build on Windows can be done with command-line tools that are part of the Windows SDK. Other externals needed for builds can be obtained in Windows versions. It is how Visual Studio works -- it spawns command-line operations. So long as the SVN Working copy has the correct ignore settings, once could then create projects if desired, and there might be a way to download a .zip of project files that could be expanded into a build slot in the Working copy. Although, since most of what is needed is in text and XML files, there is a way to do this at a lower level that doesn't require binaries in the source tree. That should get rid of the CygWin dependency for Windows builds and let the available tools work at their best. I think the bigger challenge is to be able to do incremental builds or even build libraries shared within AOO separately as a way to get problems of massive clean builds that take hours and don't help localize errors much. That's probably the way to build up the Windows build case anyhow. Note: If one is careful about the filepath rewriting business in CygWin, one can execute Windows command-line tools pretty easily, using .bat files as bridges -- .bat files execute properly in CygWin and MSys where I have tried it, and they will work correctly when used directly via cmd.exe. That is also how one gets environment variables set properly, etc. (One needs to get around a couple of glitches where CygWin and its cousins treat the environment as case sensitive but the Windows SDK tools do not.) And then there's [unit] testing to consider. - Dennis > > Build it. > > In particular, use of a UNIX-derived shell must not be required for > Windows builds. > > In this vision, the core work would be done on Windows, using an IDE. > There would still be a need for a small number of Linux etc. people to > handle building for their environments, and to keep the Windows-based > developers from building in unwarranted assumptions. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Putting Windows First ( was RE: null)
On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Wednesday, July 13, 2016 12:57 To: dev@openoffice.apache.org Subject: Re: Putting Windows First ( was RE: null) [ ... ] [orcmid] I would like to suggest a way of squeezing out from between the rock and hard place, and getting more developers: Separate out the Windows build process. Pick one of the common IDE's, and create a project file that sets all environment variables for Windows. Get as close as possible to the step-by-step build instructions for Windows being: Check out the source from SVN. Open the project file in $IDE$. [orcmid] I don't think it is necessary to have an IDE commitment. Everything needed to do a build on Windows can be done with command-line tools that are part of the Windows SDK. Other externals needed for builds can be obtained in Windows versions. It is how Visual Studio works -- it spawns command-line operations. So long as the SVN Working copy has the correct ignore settings, once could then create projects if desired, and there might be a way to download a .zip of project files that could be expanded into a build slot in the Working copy. Although, since most of what is needed is in text and XML files, there is a way to do this at a lower level that doesn't require binaries in the source tree. That should get rid of the CygWin dependency for Windows builds and let the available tools work at their best. I think the bigger challenge is to be able to do incremental builds or even build libraries shared within AOO separately as a way to get problems of massive clean builds that take hours and don't help localize errors much. That's probably the way to build up the Windows build case anyhow. Note: If one is careful about the filepath rewriting business in CygWin, one can execute Windows command-line tools pretty easily, using .bat files as bridges -- .bat files execute properly in CygWin and MSys where I have tried it, and they will work correctly when used directly via cmd.exe. That is also how one gets environment variables set properly, etc. (One needs to get around a couple of glitches where CygWin and its cousins treat the environment as case sensitive but the Windows SDK tools do not.) And then there's [unit] testing to consider. There are already unit tests that run in Eclipse. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
On 31/08/2016 16:26, Dennis E. Hamilton wrote: > One can always create an independent entity. It hasn't happened. By now, > the odds are clearly that it will not. The Document Foundation is an independent entity, building upon the OOo 3.x code base. > My considered opinion is that the greatest barrier is lack of a meaningful > business/operation/funding model. The business model is giving away the product, but selling support services. Sun almost understood that model. Oracle understands that model,but would rather throw away their product, than actually implement that model at the SOHO, or smaller scale. As a business model, it works for most of the Apache projects that emerged from Incubation, and stayed out of the Attic. > I also don't think working on Apache OpenOffice is much of a resume builder, What builds resumes is the specific contributions one makes. The specific project, be it AOo, No Man's Sky, BLEACHER, or anything else, is irrelevant. >since there is no other project like it and probably will never be. At least four other office suites utilize code from AOo. There are at least a thousand office suites for Android, and iOS, for which AOo development is a useful starting point. > If my appraisal is sound, that leaves us with the question about > sustainability of the Apache OpenOffice project itself, Go back to the revenue generation model. Back in the 2003-2005 time frame, there were several organizations licensing their rebranded version of OOo for between US$20 and US$5,000 per seat, per year. For various reasons, I quit tracking that data, and thus don't know what the current situation is. A decade ago, it was fairly difficult to find worksites of more than 1,000 that used OOo. Today, worksites of more than 5,000 users, using an OOo derivative, are not not that scarce. Somebody is providing tech support for those worksites. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Merge with LibreOffice?
On 31/08/2016 16:26, Dennis E. Hamilton wrote: > The question I am left with is this: If a cousin development provides what > you want, why are you not satisfied with that? There are functions and capabilities in AOo that are not in LibO or EO. There are functions and capabilities in EO that are not in LibO or AOo. There are functions and capabilities in LibO that are not in AOo or EO. As such, until one of those contains all of the functions and capabilities found in the other two, there will always be users whose use case will require at least two, if not all three be installed. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Merge with LibreOffice?
On Wed, Aug 31, 2016 at 2:38 PM, toki wrote: > On 31/08/2016 16:26, Dennis E. Hamilton wrote: > > > The question I am left with is this: If a cousin development provides > what you want, why are you not satisfied with that? > > There are functions and capabilities in AOo that are not in LibO or EO. > There are functions and capabilities in EO that are not in LibO or AOo. > There are functions and capabilities in LibO that are not in AOo or EO. > > As such, until one of those contains all of the functions and > capabilities found in the other two, there will always be users whose > use case will require at least two, if not all three be installed. > I can't speak for what power users there may be out there, but I suspect I personally am much more likely to pick one and then defend my decision to the death, even if it means adjusting my usage pattern to fit. My criteria may be financial, or functional, or even socio-political, but whichever it is, it's enough of an effort to change my word processor AND my mind that it's not likely to happen on a casual basis, much less a day-to-day one. Don
Re: Putting Windows First ( was RE: null)
Hi Patricia; I, for one, appreciate the idea: 80% of the users are Windows people and the project should be focusing on improving the experience on that platform. OTOH, most of the active developers work on UNIX variant (and I suspect FreeBSD is the majority lately). I conceptually understand the Windows port is critical and would like to see it improve but I don't have the time or expertise to work on a platform different than the one I am using now. May I say this shouldn't stop you: just create a branch and fork a more windows-friendly port, we can cross-merge features between both branches. Also the capstone2013 branch, while badly outdated, may give new hints for a Windows build system. Pedro. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Putting Windows First ( was RE: null)
On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote: -Original Message- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Wednesday, July 13, 2016 12:57 To: dev@openoffice.apache.org Subject: Re: Putting Windows First ( was RE: null) [ ... ] [orcmid] I would like to suggest a way of squeezing out from between the rock and hard place, and getting more developers: Separate out the Windows build process. Pick one of the common IDE's, and create a project file that sets all environment variables for Windows. Get as close as possible to the step-by-step build instructions for Windows being: Check out the source from SVN. Open the project file in $IDE$. [orcmid] I don't think it is necessary to have an IDE commitment. Everything needed to do a build on Windows can be done with command-line tools that are part of the Windows SDK. Other externals needed for builds can be obtained in Windows versions. It is how Visual Studio works -- it spawns command-line operations. To me, direct use of command line tools feels like an awkward half-way step between the punch cards I used when I started programming, and the IDE's I use for most of my programming now. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
On 08/31/2016 09:26 AM, Dennis E. Hamilton wrote: > One can always create an independent entity. It hasn't happened. By now, > the odds are clearly that it will not. I suspect that folks who would pursue > that avenue do not see a meaningful opportunity. > > My considered opinion is that the greatest barrier is lack of a meaningful > business/operation/funding model. In addition, there is an insufficient > supply of developers having the capacity, capability, and will to provide > material improvements to Apache OpenOffice. Whatever the pool might be, it > is aging and shrinking for many reasons. The affliction that Apache > OpenOffice suffers under in that respect also besets any organization set up > to support the code, even with paid developers. > > I also don't think working on Apache OpenOffice is much of a resume builder, > since there is no other project like it and probably will never be. I think this all depends on what one's interests consists of. If you're a C++ programmer looking for a challenging opportunity, Apache OpenOffice might be just what you had in mind for a resume builder. There are far easier projects to build an open-source reputation with, ones that build developer skills in areas where there is a growing and future demand. > > Having suggested this much, I don't think it is meaningful to address how an > external entity could "ensure they work on the AOO codebase using the ASF > way." > > If my appraisal is sound, that leaves us with the question about > sustainability of the Apache OpenOffice project itself, and what the > consequences of unsustainability are. > > - Dennis > > >> -Original Message- >> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] >> Sent: Monday, July 11, 2016 14:04 >> To: dev@openoffice.apache.org >> Subject: RE: Independent Entity to Develop and Further AOO >> >> There is a bit to discuss about how "The entity should ensure they work >> on the AOO codebase using the ASF way" is workable or not. In >> particular, no such entity can direct the project at Apache or otherwise >> effectively govern it. More about that later. >> >> There is another option, summarized below. One might also consider this >> as a reality check. That is, if that is not feasible, it may be that no >> other arrangement is. >> >>> -Original Message- >>> From: Suminda Dharmasena [mailto:sirinath19...@gmail.com] >>> Sent: Monday, July 11, 2016 00:23 >>> To: market...@openoffice.apache.org; dev@openoffice.apache.org >>> Subject: Independent Entity to Develop and Further AOO >>> >>> Hello, >>> >>> I am writing to see if the current AOO Dev team would like to create >> an >>> independent entity which can: >>> >>>- Do trainings >>>- Accept funds and have pay developers >>>- Write commercial books / online tutorials with sponsorship >>> >>> This can be used have paid developers working on the project. Maybe >>> initial >>> sponsorship can come from an organisation like Redhat, Pivotal or >> Micro >>> Focus if they are interested. Perhaps companies which used the code >> base >>> in >>> the past like IBM or Oracle. >>> >>> The entity should ensure they work on the AOO codebase using the ASF >>> way. >>> >>> Suminda >> [orcmid] >> >> AN ALTERNATIVE APPROACH >> >> Another way to interact and support Apache OpenOffice in terms of >> collaborative contributions is as follows. >> >> 1. Establish a downstream producer, TeamX (for example), that provides >> releases of derivative software based on Apache OpenOffice. >> >> 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the >> use of Apache OpenOffice source code. Apache trademark requirements are >> satisfied in any use as part of the branding of the downstream product. >> >> 3. Assumption #2: New code and modifications to the TeamX derivative >> are also under ALv2. >> >> 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs >> are contributed back upstream to Apache OpenOffice. Components from >> other sources would, of course, be contributed upstream to those >> sources. Contributions and joint concerns might lead to use of the >> OpenOffice bugzilla as a coordination point. >> >> 5. Opportunity. The business model, organization, and governance of >> TeamX is not of concern to the ASF. >> >> 6. Opportunity. The Apache Software Foundation requirements beyond >> honoring of the ALv2 that govern Apache projects serving the public >> interest do not apply, although TeamX could operate in a harmonious >> manner. >> >> 7. Opportunity. So long as there is clear separation and no comingling >> in source-code files, TeamX is not constrained from also using code or >> components from other projects, such as those using licenses such as the >> MPL or, under appropriate conditions, something like LGPL2, with >> appropriate honoring of those licenses too. However, to avoid tainting >> of upstream source-code contributions back to Apache Ope
RE: Independent Entity to Develop and Further AOO
> -Original Message- > From: toki [mailto:toki.kant...@gmail.com] > Sent: Wednesday, August 31, 2016 11:30 > To: dev@openoffice.apache.org > Subject: Re: Independent Entity to Develop and Further AOO > > On 31/08/2016 16:26, Dennis E. Hamilton wrote: > > > One can always create an independent entity. It hasn't happened. By > now, the odds are clearly that it will not. > > The Document Foundation is an independent entity, building upon the OOo > 3.x code base. > > > My considered opinion is that the greatest barrier is lack of a > meaningful business/operation/funding model. > > The business model is giving away the product, but selling support > services. Sun almost understood that model. Oracle understands that > model,but would rather throw away their product, than actually implement > that model at the SOHO, or smaller scale. > > As a business model, it works for most of the Apache projects that > emerged from Incubation, and stayed out of the Attic. [orcmid] I think that is the case because downstream producers, who get the support business, contribute to their upstream framework or source-code distributor. What indication is there that any of that is working for Apache OpenOffice? Maybe if we stopped shipping binaries? How would that work for the individuals who seem to dominate our download consumption? > > > I also don't think working on Apache OpenOffice is much of a resume > builder, > > What builds resumes is the specific contributions one makes. The > specific project, be it AOo, No Man's Sky, BLEACHER, or anything else, > is irrelevant. > > >since there is no other project like it and probably will never be. > > At least four other office suites utilize code from AOo. There are at > least a thousand office suites for Android, and iOS, for which AOo > development is a useful starting point. > > > If my appraisal is sound, that leaves us with the question about > sustainability of the Apache OpenOffice project itself, > > Go back to the revenue generation model. > > Back in the 2003-2005 time frame, there were several organizations > licensing their rebranded version of OOo for between US$20 and US$5,000 > per seat, per year. For various reasons, I quit tracking that data, and > thus don't know what the current situation is. > > A decade ago, it was fairly difficult to find worksites of more than > 1,000 that used OOo. Today, worksites of more than 5,000 users, using an > OOo derivative, are not not that scarce. Somebody is providing tech > support for those worksites. [orcmid] And how does any of that contribute to the development of Apache OpenOffice? As far as I can tell, those downstream activities are invisible to the project. - Dennis > > jonathon > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Putting Windows First ( was RE: null)
> -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Wednesday, August 31, 2016 14:20 > To: dev@openoffice.apache.org > Subject: Re: Putting Windows First ( was RE: null) > > On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote: > > > > > >> -Original Message- From: Patricia Shanahan > >> [mailto:p...@acm.org] Sent: Wednesday, July 13, 2016 12:57 To: > >> dev@openoffice.apache.org Subject: Re: Putting Windows First ( was > >> RE: null) > >> > > [ ... ] [orcmid] > >> I would like to suggest a way of squeezing out from between the > >> rock and hard place, and getting more developers: > >> > >> Separate out the Windows build process. Pick one of the common > >> IDE's, and create a project file that sets all environment > >> variables for Windows. Get as close as possible to the step-by-step > >> build instructions for Windows being: > >> > >> Check out the source from SVN. > >> > >> Open the project file in $IDE$. > > [orcmid] > > > > I don't think it is necessary to have an IDE commitment. > > > > Everything needed to do a build on Windows can be done with > > command-line tools that are part of the Windows SDK. Other externals > > needed for builds can be obtained in Windows versions. It is how > > Visual Studio works -- it spawns command-line operations. > > To me, direct use of command line tools feels like an awkward half-way > step between the punch cards I used when I started programming, and the > IDE's I use for most of my programming now. [orcmid] The advantage is that the command-line operation is agnostic about choice of IDE so long as one can use a chosen IDE successfully. You can also build make projects in Visual Studio. You're likely to find Git integration built in and have to do more work for SVN, but it is not a lot more work. I haven't tried Visual Code, but that might be a likely candidate too, without any of the heavyweight qualities of Visual Studio. It's integration is rather lightweight but I don't know how well it works with C++. Probably the biggest integration points (apart from source control) are line matching of compiler error messages and also build messages to a window in the IDE. I assume that anything that uses the Windows SDK and command-line compiler will handle that. I am not opposed to IDE integration, so long as it is on top of the Working check-out. When we end up making a choice of IDE in the SVN and the delivered buildable source releases, I think that won't fly. We will be forcing someone to operate with multiple tool sets and not their chosen one. Let me put it this way. We want to be able to do quality Windows builds of Windows binaries. The fall-line case is to use a freely-available native Windows toolchain. At the moment there are no IDE dependencies in the Apache OpenOffice system, and having folks be able to use IDEs is an orthogonal (but interacting) consideration. We need to enable that without imposing one, it seems to me. In any case, we are a long way from any solution to this. - Dennis > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Release 4.2: Regressions for investigation
Again, I have only looked at a few of these. http://bit.ly/2bCshfO It would be valuable for QA folks to retest with 4.1.2. The Mac one with Base is a very big deal and, until we have a dedicated Mac builder, person or buildbot, it unlikely it will be resolved. -- Kay Schenk Apache OpenOffice "Things work out best for those who make the best of the way things work out." -- John Wooden - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < dennis.hamil...@acm.org> wrote: > > > > -Original Message- > > From: toki [mailto:toki.kant...@gmail.com] > > Sent: Wednesday, August 31, 2016 11:30 > > To: dev@openoffice.apache.org > > Subject: Re: Independent Entity to Develop and Further AOO > > > > On 31/08/2016 16:26, Dennis E. Hamilton wrote: > > > I think that is the case because downstream producers, who get the support > business, contribute to their upstream framework or source-code distributor. > > What indication is there that any of that is working for Apache > OpenOffice? Maybe if we stopped shipping binaries? How would that work > for the individuals who seem to dominate our download consumption? Since the "downstream" producers seem better equipped to deliver signed and vulnerability-corrected binaries to non-specialist consumers on a timely schedule, maybe delegating downloads to them would be a good option for the project? S.
Re: Independent Entity to Develop and Further AOO
Am 01.09.2016 um 00:59 schrieb Simon Phipps: > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton < > dennis.hamil...@acm.org> wrote: > >> >> >>> -Original Message- >>> From: toki [mailto:toki.kant...@gmail.com] >>> Sent: Wednesday, August 31, 2016 11:30 >>> To: dev@openoffice.apache.org >>> Subject: Re: Independent Entity to Develop and Further AOO >>> >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote: >>> >> I think that is the case because downstream producers, who get the support >> business, contribute to their upstream framework or source-code distributor. >> >> What indication is there that any of that is working for Apache >> OpenOffice? Maybe if we stopped shipping binaries? How would that work >> for the individuals who seem to dominate our download consumption? > > > Since the "downstream" producers seem better equipped to deliver signed and > vulnerability-corrected binaries to non-specialist consumers on a timely > schedule, maybe delegating downloads to them would be a good option for the > project? Stopping shipping binaries would cause some negative effect for our project, so it might be an option, but not best one. Binaries made by our community are essential for our QA. Without them we stand "with empty hands" in the public with negative effects for our brand and image. Supporting our users by community members would break down. So the impact for the improvement of our commity would be tremendous, if we "delegate" this tasks to a third party. Kind regards Michael signature.asc Description: OpenPGP digital signature