Re: About Me (New Volunteer)
Zim, welcome to the project and again your starting point is to get OpenOffice to build. Follow https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO and let us know if you need assistance. You complain you are not receiving any answers, but you are missing some (see the one from Alexandro below) since you are not subscribed to the list. Read http://openoffice.apache.org/mailing-lists.html to know how to fix this. Regards, Andrea. On 26/05/2014 Alexandro Colorado wrote: That's excellent there are some guides for PyUNO and good tutorials and sample code here: http://wiki.openoffice.org/wiki/Python On Mon, May 26, 2014 at 2:38 AM, zimuzo ezeozue zimuzostan...@gmail.comwrote: Im interested in the OpenOffice PyUno bridge On Mon, May 26, 2014 at 8:21 AM, zimuzo ezeozue zimuzostan...@gmail.com wrote: Hi, My name is Zim. I'm a Nigerian software developer. Currently an undergraduate student studying Mechanical Engineering. I'm interested in building for AOO for the following reasons: 1. To improve my skills as a developer. 2. Im passionate about the open source community and I would love to be a contributor This is my first attempt at an open source project. I currently work with a startup https://callbase.co/ . I have a personal project i worked on at some time with my brother http://www.nepasituation.com/ . Im proficient in Java. I know a some Python and Javascript. With a little C++. Im eager to hear from someone. Thanks - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Tracking bugs like Issue 124985 - [Meta] Meta Bug for collecting bugs which appeal for AOO 4.1.x
On 26/05/14 20:13, Rainer Bielefeld wrote: Hi Herbert, I think we have some misunderstanding here. It's an essential that information should be consistent at any place for Bugzilla. Here an overview concerning priority /severity of the issues listed in the meta-issue; ! Critical major normaltrivial ! Total ---!-!-- P1 !1 . . . ! 1 P2 !. . . 1 ! 1 P3 !. 4 5 . ! 9 ---!-!-- Tot!1 4 5 1 ! 11 So my question is why Issue 114361 with severity trivial has been considered by godlike decision (there is no reasoning, neither in Issue 124985 nor in Issue 114361) so serious that it has been added added to the meta bug? With some minimum carefulness the severity would have been rised to major or more, the dataloss keyword would have been added, so that the decision will be comprehensible. I did that now in Issue 114361 Common known characteristics of unresolved Issue 124985 blocking Bug reports you find in Report [1] (More than 3400). So the question is why have 11 been picked as blocker for the meta issue, but more of 3400 not [2]? The answer is quite simple because developers took care of these issues and provided a fix or have a fix in place. We don't fix issues in the order they are detected or reported. With some minimum corrections for the criteria of possible Meta bug blockers I can reduce the number by 90% [3] [4] Sorts these issues by priority /severity, the 12 with critical + P2 need some urgent review as I did for Issue 118725 - images dropped by random https://issues.apache.org/ooo/show_bug.cgi?id=118725 Issue 122780 https://issues.apache.org/ooo/show_bug.cgi?id=122780 and others And so on. Such systematic working is the only way for real progress. it is indeed useful but again anybody can focus on the issues they are interested in. And a closer look on the issues in the meta issue will show that they are all valid and serious enough. And in general we have so many bug reports that it is nearly impossible to to address them all, at least from a developer perspective. And if issues are not reproduceable or bug docs are missing etc. they got easy ignored because we have many others with better descriptions etc. But I agree 100% that we should add as much as possible meta info in the issue to make the selection or review as easy as possible. In case of 114361 the data loss keyword is of course very useful to make clear that this issue is a good candidate. We received some reports regarding this or similar behaviour and Oliver did a more careful analysis and found the root cause. The good thing is that he searched for similar older issues and found one. If after some work we have valid data in the bug reports Meta Bugs indeed can be useful to show up dependencies and relations what are not simply visible in the bug reports. For anything else queries like https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamedlist_id=149854namedcmd=Potential411Blockers (shared with registered users) are much more powerful, especially in projects with bigger community than AOO and much bug tracker activity (20 reports per day, not only 2). I think we are all in the same boat and have a common understanding but we are not yet in the situation where we have a cleaned bugtracker. And we have too less volunteers to help either in reviewing the issues or fix them. And of course you drove an active volunteer (maybe over motivated) away with a somewhat strict and of course your personal opinion how QA work should be done. You can now disagree and can move away as well (I hope you do not) but it is as it is. And we have no ideal world in such a huge open source project. We can learn from each other and can improve over time. But it is always important how we collaborate and work together. For now I am in favor to address the most recent issues first and keep an eye on the priority and incoming issues in general where possible. Kind regards Juergen Best regards Rainer - 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: Tracking bugs like Issue 124985 - [Meta] Meta Bug for collecting bugs which appeal for AOO 4.1.x
Hi Rainer, On 26.05.2014 20:13, Rainer Bielefeld wrote: It's an essential that information should be consistent at any place for Bugzilla. +1 Here an overview concerning priority /severity of the issues listed in the meta-issue; ! Critical major normaltrivial ! Total ---!-!-- P1 !1 . . . ! 1 P2 !. . . 1 ! 1 P3 !. 4 5 . ! 9 ---!-!-- Tot!1 4 5 1 ! 11 Regressions are also an important consideration. So my question is why Issue 114361 with severity trivial has been considered by godlike decision (there is no reasoning, neither in Issue 124985 nor in Issue 114361) so serious that it has been added added to the meta bug? With some minimum carefulness the severity would have been rised to major or more, the dataloss keyword would have been added, so that the decision will be comprehensible. I did that now in Issue 114361 A higher severity was very much warranted for this data loss. Data loss sounds a bit like an abstract concept but in this case it was I had a perfectly fine presentation, saved it and some pics are gone!!!. So the meta-issue helped to identify that this important issue was not properly flagged and would have been overlooked if we had only used the query as suggested. +1 for the meta-issue then. Common known characteristics of unresolved Issue 124985 blocking Bug reports you find in Report [1] (More than 3400). So the question is why have 11 been picked as blocker for the meta issue, but more of 3400 not [2]? For the references [1], [2] or [3] in your mail I cannot find their actual links, but I think I know what you mean. As said the meta-issue is only intended as a publicly visible reminder and best-effort overview what should eventually get into an eventual bugfix release if we decide whether we'll need one. The meta-issue helps with this discussion. +1 for the meta-issue. Whether they really should get into an eventual bugfix release would be decided later by requesting the blocker flag. I'd say good criteria for such issues are: - regressions - crashes - data losses * risk of new regressions So even if a bug is only minor; if it is a regression, a fix is available and low risk it should get into a bugfix release. Such a bug would not be caught by a query for major issues, but IMHO they are great candidates anyway. Should we decide that our bugfix releases must only contain fixes for bugs with major severity then this is fine as well. The bugs below this level would be removed from nomination. I'd advise against ignoring such fixes though. With some minimum corrections for the criteria of possible Meta bug blockers I can reduce the number by 90% [3] [...] Such systematic working is the only way for real progress. This systematic work is very important indeed and I appreciate and have the deepest respect for our QA volunteer who work on it. If after some work we have valid data in the bug reports Meta Bugs indeed can be useful to show up dependencies and relations what are not simply visible in the bug reports. For anything else queries like https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamedlist_id=149854namedcmd=Potential411Blockers (shared with registered users) are much more powerful, especially in projects with bigger community than AOO and much bug tracker activity (20 reports per day, not only 2). I'm logged in and have all the rights needed but I can't see that query. On the other hand the meta-issue is visible to everyone without any trouble... Best regards, Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
weekly news or monthly news ?
Hello, we see that unfortunately the weekly news [1] are been some time no longer published. I am worried that the good approach of weekly news thereby is lost and the weekly news disappear. Would it not be a better way to accept it not enough new going on every week and therefore publish the same monthly news, _but that really consistent_? Greetings, Jörg [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40508638 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Lazy Consensus] link to a german forum
On 26.05.2014 23:08, Andrea Pescetti wrote: Hagar Delest wrote: I agree, we should add the link on the landing page (which has still an old logo BTW). Adding something like (3rd party) would be fine. OK. So can someone tell us the best way to write Third party forums in German in German? Unabhängige befreundete deutsch-sprachige Foren would be a good translation IMHO. It means Friendly but independent German-speaking forums. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Local marketing and resources (Re: Native Language and Localization pages on cwiki might benefit from some organization)
On 26/05/2014 Jörg Schmidt wrote: Yes, a local community must grow themselves, but they need structures within the overall international project. ... I think we need to ask ourselves these questions of local structures and _long-term_ need to create such structures. We don't need to create them in a formal way. At least, Apache tries to be as flat as possible here. For a number of reasons, for example, Apache has a policy that all project decisions are community decisions, and do not depend on an individual. So personal responsibilities (like: being the press contact for Germany) are generally not officially granted: rather than having a press contact for Germany, we have a generic press alias see http://openoffice.apache.org/press.html that is used to route requests to the appropriate person depending on the request. This doesn't forbid that, informally, a person takes responsibility for a certain activity. But we don't officially grant the many roles we used to grant in the past. common part (English original, replicate for other languages; this includes the layout) and a specific part where materials in native language will be shown, specific to each language (documentation in native language, announces about local events...) That's clear, but please look practice. It is to say, a difference that _should be_ a English original there or it _must be_ a English original there. There must be some pages common to all languages (translated from the English site); and there can be content in German only, or French only, that only appears on the German/French website, like the 10-page article in German you imagine; then, if this content is good to have in other languages, someone can translate it to English and put it on the English site; but it is fine, and consistent with what we have now, to host language-specific content. I am, for example, believe that we could get enough donations for Open Office in Germany to fund our local work and that could be used for general purposes of Apache at the same time still have money left over. But we need clear agreements for it, because of course the donors want their donation is tax deductible, and that's a question of local law. Jan wrote a couple good points, and I'll add that I'm not sure how tax-deductible donations work with foreign organizations. At the moment, the biggest obstacle is that Apache never collects money to some specific purpose (and here I'm not talking about paying for developers: Apache doesn't pay for developers directly and this won't change). A massive redesign of the fundraising policy, better suited to OpenOffice and in general to those projects that could use many small donations and spend them for specific purposes, is coming and it will be one of the initial tasks for next year's Apache Board. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Lazy Consensus] link to a german forum
From: Herbert Duerr [mailto:h...@apache.org] OK. So can someone tell us the best way to write Third party forums in German in German? Unabhängige befreundete deutsch-sprachige Foren would be a good translation IMHO. It means Friendly but independent German-speaking forums. Sorry, I would not say that my suggested translation: DE - deutschsprachige Foren von Drittanbietern the best option is, but I think befreundete factually wrong, because we will linking to: http://www.openoffice.org/de/foren.html should take place and we should call there as possible all content relevant forums, but have not at all direct contacts, likewise, it is not certain that all of these forums are independent. Jörg - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Local marketing and resources (Re: Native Language and Localization pages on cwiki might benefit from some organization)
On 5/27/14, Andrea Pescetti pesce...@apache.org wrote: On 26/05/2014 Jörg Schmidt wrote: Yes, a local community must grow themselves, but they need structures within the overall international project. ... I think we need to ask ourselves these questions of local structures and _long-term_ need to create such structures. We don't need to create them in a formal way. At least, Apache tries to be as flat as possible here. For a number of reasons, for example, Apache has a policy that all project decisions are community decisions, and do not depend on an individual. So personal responsibilities (like: being the press contact for Germany) are generally not officially granted: rather than having a press contact for Germany, we have a generic press alias see http://openoffice.apache.org/press.html that is used to route requests to the appropriate person depending on the request. Who decides who is the appropriate person? If someone send an email in chineese requesting a contact, would it be routed to the chineese community or to a specific person? Who will that person be? If an event is looking for available speakers, how will press find the correct speaker closest to the location and available to give a talk? Has this situation happened before, how was it handled? This doesn't forbid that, informally, a person takes responsibility for a certain activity. But we don't officially grant the many roles we used to grant in the past. common part (English original, replicate for other languages; this includes the layout) and a specific part where materials in native language will be shown, specific to each language (documentation in native language, announces about local events...) That's clear, but please look practice. It is to say, a difference that _should be_ a English original there or it _must be_ a English original there. There must be some pages common to all languages (translated from the English site); and there can be content in German only, or French only, that only appears on the German/French website, like the 10-page article in German you imagine; then, if this content is good to have in other languages, someone can translate it to English and put it on the English site; but it is fine, and consistent with what we have now, to host language-specific content. I am, for example, believe that we could get enough donations for Open Office in Germany to fund our local work and that could be used for general purposes of Apache at the same time still have money left over. But we need clear agreements for it, because of course the donors want their donation is tax deductible, and that's a question of local law. Jan wrote a couple good points, and I'll add that I'm not sure how tax-deductible donations work with foreign organizations. At the moment, the biggest obstacle is that Apache never collects money to some specific purpose (and here I'm not talking about paying for developers: Apache doesn't pay for developers directly and this won't change). A massive redesign of the fundraising policy, better suited to OpenOffice and in general to those projects that could use many small donations and spend them for specific purposes, is coming and it will be one of the initial tasks for next year's Apache Board. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor 882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
cleaning up our sourceforge top-level directory
I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0:843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib41 weekly downloads milestones:31 weekly downloads packages6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Bad Web Link
I was just trying to download the Mac OS-X 4.1 version of open office but the link leads to version 4.0.1 instead. I used the URL to FIND the correct file to download but you might want to update this for ease by others. Thanks, * * * * * * * * * * Douglas S. Davis Information Systems Coordinator Monical Pizza Corporation 815.929.2074 - office 815.644.4863 - mobile * * * * * * * * * * This communication may contain proprietary and confidential information for the sole use of the intended recipient. If you are not the intended recipient, please note that any other dissemination, distribution, use or copying of this communication is strictly prohibited. Anyone who receives this message in error should notify the sender immediately by telephone or by return e-mail and delete it from their computer.
Re: cleaning up our sourceforge top-level directory
On Tue, May 27, 2014 at 8:00 AM, Herbert Duerr h...@apache.org wrote: I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0:843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib41 weekly downloads milestones:31 weekly downloads packages6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org I wonder if some of this is due to auto processes that are still using the old structure. We still allow for downloads of legacy OOo, so it would probably be better to move the older versions to something like our current structure -- your second option above? And, should the older packages, if it applies only to 3.3, also have its own area? Maybe someone still wants/needs these. -- - MzK Even a happy life cannot be without a measure of darkness, and the word happy would lose its meaning if it were not balanced by sadness. It is far better (to) take things as they come along with patience and equanimity. -- Carl Jung
Question for the Open Office for Android and blind users?
Hello, i think, that my question isn't right here, but this is the best place I think. Is the Android Version of Open Office fully compatible with TalkBack (The Screen Reader for blind users in Android)? I'm blind myself and this is a very important question for all blind users. If not, will this get implemented in future? Thanks for your help! Best Regards Marco --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com
Re: Question for the Open Office for Android and blind users?
Marco Retzlaff wrote: Hello, i think, that my question isn't right here, but this is the best place I think. Is the Android Version of Open Office fully compatible with TalkBack (The Screen Reader for blind users in Android)? I'm blind myself and this is a very important question for all blind users. If not, will this get implemented in future? Thanks for your help! Best Regards Marco --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com Marco; The Android version, called AndreOpen Office is a port by a third party developer and is not an official release of the Apache OpenOffice project;(see http://www.openoffice.org/porting/index.html). As such it is not supported directly by the project. It is available from https://play.google.com/store/apps/details?id=com.andropenoffice and there is a link to email the developer at the bottom of that page. He should be able to give you more details on your question. Regards Keith McKenna signature.asc Description: OpenPGP digital signature
Re: cleaning up our sourceforge top-level directory
Am 05/27/2014 05:00 PM, schrieb Herbert Duerr: I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0: 843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib 41 weekly downloads milestones: 31 weekly downloads packages 6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. wow, yes. :-O Thanks for bringing this to our attention. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others IMPORTANT: Before deciding to remove any release builds, please consider the new download webpage I'm building currently. This will offer also older AOO versions. So, when we want to offer older version, then of course they need to be available. ;-) Therefore my suggestion: - 4.1.0, 4.0.1, 4.0.0 Keep - contrib, extended Delete as it's outdated content - packages Move to archive - localized, stable Keep the 3.4.1 builds as last stable 3.x release, re-order them like the 4.x directory structure and move the 3.4.0 and older ones to archive - milestones Keep (as it's currently empty) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Question for the Open Office for Android and blind users?
Forwarding the mail to Marco as it's not sure if he is subscribed to this mailing list. Am 05/27/2014 07:29 PM, schrieb Keith N. McKenna: Marco Retzlaff wrote: Hello, i think, that my question isn't right here, but this is the best place I think. Is the Android Version of Open Office fully compatible with TalkBack (The Screen Reader for blind users in Android)? I'm blind myself and this is a very important question for all blind users. If not, will this get implemented in future? Thanks for your help! Best Regards Marco --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com Marco; The Android version, called AndreOpen Office is a port by a third party developer and is not an official release of the Apache OpenOffice project;(see http://www.openoffice.org/porting/index.html). As such it is not supported directly by the project. It is available from https://play.google.com/store/apps/details?id=com.andropenoffice and there is a link to email the developer at the bottom of that page. He should be able to give you more details on your question. Regards Keith McKenna - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bad Web Link
Am 05/27/2014 03:58 PM, schrieb Doug Davis: I was just trying to download the Mac OS-X 4.1 version of open office but the link leads to version 4.0.1 instead. I used the URL to FIND the correct file to download but you might want to update this for ease by others. thanks for your mail. Too bad ;-) that you don't tell us: a) from where you tried to download b) if you see any error message or hint text c) which OS X version you are using. But from your description it sounds as you are running 10.6 or older and tried to download from www.openoffice.org/download/. Since AOO 4.1.0 there is no longer support for older OS X systems. This should be visible in the green box and as alternative you are offered with the previous version 4.0.1. HTH Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cleaning up our sourceforge top-level directory
Am 05/27/2014 05:46 PM, schrieb Kay Schenk: On Tue, May 27, 2014 at 8:00 AM, Herbert Duerrh...@apache.org wrote: I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0:843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib41 weekly downloads milestones:31 weekly downloads packages6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org I wonder if some of this is due to auto processes that are still using the old structure. even if this would be the case. Do we want to support this for longer? I don't think so. We still allow for downloads of legacy OOo, so it would probably be better to move the older versions to something like our current structure -- your second option above? +1 And, should the older packages, if it applies only to 3.3, also have its own area? Maybe someone still wants/needs these. Then they should look for them in the ASF archive. This should be the only location for very old release builds. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cleaning up our sourceforge top-level directory
Herbert Duerr wrote: The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. This could be our fault too. It seems that localized is mainly used to serve these languages (using numbers from http://sourceforge.net/projects/openofficeorg.mirror/files/localized/ ): pl 9500 nb 3400 da 2700 es 2100 For Danish, the problem is surely coming from ourselves: we are not listing 4.1.0 at http://www.openoffice.org/da/ (discussed at http://markmail.org/message/ibhey3f7jt6b7db2 , I'll fix it now so we can see if the number decreases). For other languages, we should check our own site first! I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Breaking existing links is very bad. If people are getting these files, we can't just remove them. I'd rather work on the causes (let's see what Danish looks like in one week) and we can add a README.txt or something if you believe people are browsing the SourceForge file tree and getting lost; but files are there, they are being heavily downloaded and removing there immediately would simply cause confusion. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting a problem with the OpenOffice website
Hi, My computer will not allow me to uninstall open office. Is states there is no file path an I need to create one. Please advise how download Kind Regards Simon Furneaux T: 0151 329 2813 M: 0780 777 5791 si...@focusbestdeals.co.ukmailto:si...@focusbestdeals.co.uk [FocusMarketing_FinalLogo] www.focusbestdeals.co.ukhttp://www.focusbestdeals.co.uk/
Re: How to update, commit and publish only a single file/directory? [WAS: Re: need wiki help]
On 26/05/2014 Marcus (OOo) wrote: Am 05/26/2014 10:34 PM, schrieb Andrea Pescetti: I read his mail in this discussion as when you publish, you always publish the whole thing ... Sorry, I still can edit, update and publish a single file. What's the problem to try again on your side? OK, so I did this: 1) Committed a change to the Danish home page: http://svn.apache.org/r1597866 directly with svn 2) http://www.openoffice.org/da/index.html (I manually added index.html just in case) 3) Login via CMS bookmarklet 4) Click on [Edit] in the row for index.html 5) Click on [Update] on the top Here the URL becomes https://cms.apache.org/ooo-site/wc/update/pescetti-XXYYZZ/trunk/content/da/index.html and I get: Update complete Status Updating 'usr/local/cms/wc/ooo-site/pescetti-XXYYZZ/trunk/content/da/index.html': Uusr/local/cms/wc/ooo-site/pescetti-XXYYZZ/trunk/content/da/index.html Updated to revision 1597866. And if I go to http://ooo-site.staging.apache.org/da/index.html I see my change. But then if I go to https://cms.apache.org/ooo-site/publish?diff=1 I see many more differences than my change, including for example changes in content/download/test/index_droplist.html I didn't publish. But are you able now to do any other edits to the website and get them published without publishing my changes to http://www.openoffice.org/da/index.html ? This would show that selective publication is possible. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to update, commit and publish only a single file/directory? [WAS: Re: need wiki help]
Am 05/27/2014 10:15 PM, schrieb Andrea Pescetti: On 26/05/2014 Marcus (OOo) wrote: Am 05/26/2014 10:34 PM, schrieb Andrea Pescetti: I read his mail in this discussion as when you publish, you always publish the whole thing ... Sorry, I still can edit, update and publish a single file. What's the problem to try again on your side? OK, so I did this: 1) Committed a change to the Danish home page: http://svn.apache.org/r1597866 directly with svn 2) http://www.openoffice.org/da/index.html (I manually added index.html just in case) 3) Login via CMS bookmarklet 4) Click on [Edit] in the row for index.html 5) Click on [Update] on the top Here the URL becomes https://cms.apache.org/ooo-site/wc/update/pescetti-XXYYZZ/trunk/content/da/index.html and I get: Update complete Status Updating 'usr/local/cms/wc/ooo-site/pescetti-XXYYZZ/trunk/content/da/index.html': U usr/local/cms/wc/ooo-site/pescetti-XXYYZZ/trunk/content/da/index.html Updated to revision 1597866. And if I go to http://ooo-site.staging.apache.org/da/index.html I see my change. But then if I go to https://cms.apache.org/ooo-site/publish?diff=1 I see many more differences than my change, including for example changes in content/download/test/index_droplist.html I didn't publish. But are you able now to do any other edits to the website and get them published without publishing my changes to http://www.openoffice.org/da/index.html ? This would show that selective publication is possible. I've seen your changes as I've done mine in the same minutes. Great for testing this. Now I've updated only my edited files. However in the diff (with your mentioned link above) I can see also your edits on the Danish webpage. And after my publish the Danish webpage has your changes. So, I've not uncovered a hidden feature. Too bad. ;-) But OK, mystery solved. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to update, commit and publish only a single file/directory? [WAS: Re: need wiki help]
@Joe: See my last my mail. Lesson learned: I've just seen what was updated in my workspace. But there is no hint that other commits will be taken into account, too. Until you open this link: https://cms.apache.org/ooo-site/publish?diff=1 As here the truth is shown. So finally, believe in your admin or burn in hell. :-) Marcus Am 05/19/2014 11:56 PM, schrieb Joe Schaefer: I think there's some confusion about what is actually happening when you click on the Update link in the webgui. All that does is run % svn up /path/to/underlying/svn/resource on the CMS server. When you publish you are essentially doing % svn rm https://svn.apache.org/repos/infra/websites/production/ooo-site/content % svn cp https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk/content https://svn.apache.org/repos/infra/websites/production/ooo-site/content but in a single-step using svnmucc. That's all the webgui does- it's just a wrapper around the underlying svn commands. What you are working with in the webgui is an svn checkout of the site. Update just brings your current checkout up to date within the portion of the tree that you are browsing. HTH On Monday, May 19, 2014 3:44 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 05/19/2014 09:20 PM, schrieb Joe Schaefer: Sorry but technically the CMS publishes all committed changes to the staging site. The only way to partition changes is to partition your commits. but which data will be published: the content of the SVN repository or the content of the personal CMS work space? I guess the work space as I need to update it with the SVN content. Otherwise there is nothing new to publish. Thanks Marcus On Monday, May 19, 2014 3:17 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 05/19/2014 09:51 AM, schrieb Andrea Pescetti: On 29/04/2014 Marcus (OOo) wrote: The main point is *where you are* in the CMS Browse View when you click on the Update link. I tried several times, but I'm not sure it works for me. Maybe it works if we see update as update this directory. Example to update and publish only a file: 1. In your browser open, e.g., www.openoffice.org/my-dir/my-subdir/index.html. 2. Open the CMS via the bookmarklet. 3. Click on the link [Edit] in the row of the index.html file. 4. Click on the link [Update]. 5. Do your changes in the file. 6. Commit your changes. 7. On the following page click on the link [Publish]. In the last days I tried to do this for the main index.html page and for the download/devbuilds.html page. I commit to SVN directly (so I don't use the CMS for editing pages), but the rest works as you describe. So I browse to download/ in the CMS and when I update it downloads my changed devbuilds.html page and nothing else. But then, when I publish, if I Then you have update the *complete directory* but *not the single file*. OK, I'll do it again: 1. Open w.oo.o/index.html 2. Login via CMS bookmarklet 3. Click on [Edit] in the row for index.html 4. Click on [Update] on the top 5. Only this file was updated 6. click View diff I see all the changes in download. So maybe committing through SVN means that I'm forced to update the directory, and thus if I change the main index.html file I must publish the whole site, and if I change devbuilds.html I must publish the whole subtree (download/) containing it? In that setup, indeed I wasn't able to find a command like Update this file only. No, SVN is outside of this. I do it like you. It's like I wrote on the top: The main point is *where you are* in the CMS Browse View when you click on the Update link. That means: When you are in a directory, e.g., download/ and click on Update then you get every new thing of this directory. But when a single file, e.g., devbuild.html is shown and you click on the Update link then only this file is updated and nothing else. Please can you try it and confirm? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to update, commit and publish only a single file/directory? [WAS: Re: need wiki help]
On 05/27/2014 01:30 PM, Marcus (OOo) wrote: @Joe: See my last my mail. Lesson learned: I've just seen what was updated in my workspace. But there is no hint that other commits will be taken into account, too. Until you open this link: https://cms.apache.org/ooo-site/publish?diff=1 As here the truth is shown. So finally, believe in your admin or burn in hell. :-) Marcus Well maybe not burn in hell, but at least gain some truth. Reviewing this diff can be is very important at times. :) Am 05/19/2014 11:56 PM, schrieb Joe Schaefer: I think there's some confusion about what is actually happening when you click on the Update link in the webgui. All that does is run % svn up /path/to/underlying/svn/resource on the CMS server. When you publish you are essentially doing % svn rm https://svn.apache.org/repos/infra/websites/production/ooo-site/content % svn cp https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk/content https://svn.apache.org/repos/infra/websites/production/ooo-site/content but in a single-step using svnmucc. That's all the webgui does- it's just a wrapper around the underlying svn commands. What you are working with in the webgui is an svn checkout of the site. Update just brings your current checkout up to date within the portion of the tree that you are browsing. HTH On Monday, May 19, 2014 3:44 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 05/19/2014 09:20 PM, schrieb Joe Schaefer: Sorry but technically the CMS publishes all committed changes to the staging site. The only way to partition changes is to partition your commits. but which data will be published: the content of the SVN repository or the content of the personal CMS work space? I guess the work space as I need to update it with the SVN content. Otherwise there is nothing new to publish. Thanks Marcus On Monday, May 19, 2014 3:17 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 05/19/2014 09:51 AM, schrieb Andrea Pescetti: On 29/04/2014 Marcus (OOo) wrote: The main point is *where you are* in the CMS Browse View when you click on the Update link. I tried several times, but I'm not sure it works for me. Maybe it works if we see update as update this directory. Example to update and publish only a file: 1. In your browser open, e.g., www.openoffice.org/my-dir/my-subdir/index.html. 2. Open the CMS via the bookmarklet. 3. Click on the link [Edit] in the row of the index.html file. 4. Click on the link [Update]. 5. Do your changes in the file. 6. Commit your changes. 7. On the following page click on the link [Publish]. In the last days I tried to do this for the main index.html page and for the download/devbuilds.html page. I commit to SVN directly (so I don't use the CMS for editing pages), but the rest works as you describe. So I browse to download/ in the CMS and when I update it downloads my changed devbuilds.html page and nothing else. But then, when I publish, if I Then you have update the *complete directory* but *not the single file*. OK, I'll do it again: 1. Open w.oo.o/index.html 2. Login via CMS bookmarklet 3. Click on [Edit] in the row for index.html 4. Click on [Update] on the top 5. Only this file was updated 6. click View diff I see all the changes in download. So maybe committing through SVN means that I'm forced to update the directory, and thus if I change the main index.html file I must publish the whole site, and if I change devbuilds.html I must publish the whole subtree (download/) containing it? In that setup, indeed I wasn't able to find a command like Update this file only. No, SVN is outside of this. I do it like you. It's like I wrote on the top: The main point is *where you are* in the CMS Browse View when you click on the Update link. That means: When you are in a directory, e.g., download/ and click on Update then you get every new thing of this directory. But when a single file, e.g., devbuild.html is shown and you click on the Update link then only this file is updated and nothing else. Please can you try it and confirm? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Even a happy life cannot be without a measure of darkness, and the word happy would lose its meaning if it were not balanced by sadness. It is far better (to) take things as they come along with patience and equanimity. -- Carl Jung - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For
Re: Local marketing and resources (Re: Native Language and Localization pages on cwiki might benefit from some organization)
Alexandro Colorado wrote: On 5/27/14, Andrea Pescetti wrote: http://openoffice.apache.org/press.html that is used to route requests to the appropriate person depending on the request. Who decides who is the appropriate person? If someone send an email in chineese requesting a contact, would it be routed to the chineese community or to a specific person? Who will that person be? If an event is looking for available speakers, how will press find the correct speaker closest to the location and available to give a talk? Has this situation happened before, how was it handled? We never received this kind of requests. Most of the times press@ is used for simple requests, you can read http://www.openoffice.org/marketing/press_kit.html to have an idea of the most frequently asked questions. The press@ alias goes to the whole PMC, so it's still a rather large group and can deal with no problems with simple requests. If requests like the above ones (say, an event in India looking for speakers and contacting press@ to find a speaker) occur, the person making the request will maybe be told to contact the mailing lists. But nothing like this happened so far. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cleaning up our sourceforge top-level directory
On Tue, May 27, 2014 at 11:58 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 05/27/2014 05:46 PM, schrieb Kay Schenk: On Tue, May 27, 2014 at 8:00 AM, Herbert Duerrh...@apache.org wrote: I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0:843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib41 weekly downloads milestones:31 weekly downloads packages6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org I wonder if some of this is due to auto processes that are still using the old structure. even if this would be the case. Do we want to support this for longer? I don't think so. We still allow for downloads of legacy OOo, so it would probably be better to move the older versions to something like our current structure -- your second option above? +1 And, should the older packages, if it applies only to 3.3, also have its own area? Maybe someone still wants/needs these. Then they should look for them in the ASF archive. This should be the only location for very old release builds. Marcus sure...that's fine. I never think about the archives I guess. :/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Even a happy life cannot be without a measure of darkness, and the word happy would lose its meaning if it were not balanced by sadness. It is far better (to) take things as they come along with patience and equanimity. -- Carl Jung
