Re: [RELEASE]: proposed directory structure on dist
On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/... .../dist/incubator/ooo/files/3.4.0/localized/hu/... .../dist/incubator/ooo/files/3.4.0/localized/it/... .../dist/incubator/ooo/files/3.4.0/localized/ja/... .../dist/incubator/ooo/files/3.4.0/localized/nl/... .../dist/incubator/ooo/files/3.4.0/localized/pt-BR/... .../dist/incubator/ooo/files/3.4.0/localized/ru/... .../dist/incubator/ooo/files/3.4.0/localized/zh-CN/... .../dist/incubator/ooo/files/3.4.0/localized/zh-TW/... Note that I don't
Re: RC Readmes point to Wiki ML Page that needs Update
On 4/27/12 9:59 PM, Andrea Pescetti wrote: On 24/04/2012 Jürgen Schmidt wrote: The source is in readlicense_oo/docs/readme/readme.xrm. I would suggest that we define first how we want handle it in the future. And a translated version of the README is from my perspective a very useful. The README is already localized; at least, in the Italian version I still see the text that we translated years ago, and that anyway is badly outdated now, like the English version analyzed by Dennis at https://issues.apache.org/ooo/show_bug.cgi?id=119217 no surprise to me, once we have updated the English version the translation should be triggered automatically. Juergen
Re: Seeking fun facts about AOO 3.4
Hi, On 30.04.2012 00:44, Rob Weir wrote: I'm looking for interesting factoids about AOO 3.4 and the process that got us here. We started on June 13, 2011. What have we done? For example, we've had 17,340 posts to this mailing list We've fixed 291 BZ issues, 161 of which were reported since we started at Apache. We've elected 25 committers. Does anyone have other numbers? For example, how many dev snapshots have we had? We were providing developer snapshots since mid January 2012. Before we started to provide RC builds we had roundabout 10 developer snapshots as far as I remember. Best regards, Oliver. How many forum messages have we had in this period? How many unique users have we supported? How many words of translation have we added? How many source files have been edited? -Rob
Re: Distributing AOO 3.4: The 22 things we need to do before we announce
On 4/28/12 1:40 AM, Rob Weir wrote: On Fri, Apr 27, 2012 at 10:41 AM, Rob Weirrobw...@apache.org wrote: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Please review this task list and see if anything is missing. It would be great to confirm that this list is complete and to have a volunteer's name listed against each one of these tasks. I added a new task, now #2. Once we have the final files approved we should whitelist' them with Symantec, so users will get fewer false-hits from anti-virus. https://submit.symantec.com/whitelist/isv/new/ Among the information they need is URL and SHA256 hash. It looks like each language will need to be submitted separately. Ok we have currently sha1 and sha512 checksums, should we skip one of them in favor of sha256? I'm assuming only Windows. Or is Symantec used on MacOS as well? Symantec is used on Mac as well Juergen -Rob Note the additional complexity caused by having hard-coded download logic on the various NL pages. -Rob
New group Apache OpenOffice on XING
Hi, I have created a new group Apache OpenOffice on XING that is under control of the project. https://www.xing.com/net/pri344752x/aoo PPMC members with XING account who have interest to help this group as co-moderator please let me know and I will add you. The former group OpenOffice.org is still present but I failed so far to convince the moderator of this group to allow further moderators from the PMC. But I will continue to get or at least share control over this group by the PPMC. Juergen
Re: [RELEASE] new DL test...needs review and comments, and probably correction
2012/4/30 Kay Schenk kay.sch...@gmail.com: Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all operates, it took me forever to fix this one aspect. I could have not bothered with this but well, I didn't want to lead folks astray with a not found -- so they will now get sent to other.html. So, please test with what you've got and I hope for ALL platforms that we do support, you get a link that looks to be correct. ps. I'm assuming that we will house the actual source artifact from Apache and this will show up in other.html as well when someone provides this information. Going to that page, I enter on a loop of pop-ups: the first one says schema:aoo_incubating, the second one Platform:linux 64-bit and then this message: myURLlink :a href=http://sourceforge.net/projects/openofficeorg.mirror/files/localized/es/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86-64_install-rpm_es.tar.gz/download; title = http://sourceforge.net/projects/openofficeorg.mirror/files/localized/es/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86-64_install-rpm_es.tar.gz/download Then everything starts again with some variants (a message saying hasMirroLink:true) and after another loop I finally land on the download page. This happens with firefox 12 and konqueror 4.8.2. Regards Ricardo
Re: Logo of AOO in SVG?
On 30 April 2012 02:54, Dennis E. Hamilton dennis.hamil...@acm.org wrote: It's tricky to find these because they are not shown or linked on the page itself, even though they have been uploaded as attachments. That's because I didn't have time and I don't want to spend time if it is not going to be useful. A lot of pressure in my real work at the moment. I notice that the vector-graphic versions don't render so well when displayed with IE9. The idea is not necessarily to use these directly but to produce the raster versions from them at whatever size and resolution is necessary. If Drew has vector versions of the images the simplest solution is to upload those but since they are not in the sources I'm assuming he hasn't. In the transition vectorized logos [1], - the diffused shadow and transition background render as solid with no diffusion or transparency. For Ian's version, the shadow under the ball is not diffuse but the lighting on the ball is closer to the expected form (in IE9). Chromium on Linux does not render these perfectly either. Puts hard lines around the gulls and light area. In all views of Ian's versions, the shadow under the ball is as if the ball is suspended above the surface rather than resting on it. That was deliberate :-). I liked the look of it but easy to change. I'm certainly not a professional artist, I'm just trying to establish that we use vectors and it is not a big job to do it. The really important thing is to get definitive vectors from which all other images are derived. Also, the shadow has a hard outline and is a single tone in some viewers, but is diffused in Google Chrome. I think this is again the way different svg implementations handle things. In Inkscape the line width is defined as 0. It would be useful to test these as OOo 3.4 rc1 imports to Draw - I haven't got 3.4 installed so I can't test it. In LibO the import doesn't work at least not with any reasonable fidelity. The reflection at the top of the orb is unreal, as if the surface is different, rather than there simply being a diffuse light source above or behind the orb. In this case, IE9 renders it better. Chrome renders it as if it was a hatch cover on the orb! (an edge shows around the lighter area on the top part of the orb. Quite happy for anyone to edit it better, but I wouldn't worry too much about the svg rendering direct in a browser at this stage. It's more about having a consistent reference. Let's decide on that and then get the details right. Compare with rasterized versions of the orb, such as the Approved Logo large version at section 5 on the page itself, https://cwiki.apache.org/confluence/display/OOOUSERS/Logo+Proposals. I think the lighting on that orb is unnatural too, though not so distracting. It is also the lighting of the orb that goes back to OpenOffice.org 3.3.0, unnatural or not. It may be that those effects are available in vector graphics only by using 3D modeling of the orb and its lighting. Likewise for the defocusing that works in the transitional rasterized logo, [1]. It is going to be a challenge to find an SVG that renders consistently. It may be necessary to pick a tool where it works as needed and scaled raster versions are made where the export preserves the appearance. (Even a screen capture from a rendering of the vector graphic could be used, if the vector-graphic rendering is successful.) I think we should choose either AOO Draw.odg or svg for the definitive images and then produce png and jpgs as required from them. If the reference is at least consistent we have controlled the variables for subsequent copies. There is always a degree of subjectivity about anything artistic :-). If we go down the odg route from AOO we are at least eating our own dog food. Main disadvantage is if that then limits it to odg on AOO to be sure of it rendering consistently. If we use svg on Inkscape it is supporting the W3C standard which even though differently implemented now on different browsers has probably the best chance of converging to something consistent as HTML5 gets a grip. Using odg might have the advantage of providing a focus for svg import export filters. At least they should work accurately with our logos :-). Perhaps they will in RC1 if so it would be a selling point over LibO ;-). That's all I can tell by a comparative inspection of the rendered images. - Dennis -Original Message- From: Ian Lynch [mailto:ianrly...@gmail.com] Sent: Sunday, April 29, 2012 15:57 To: ooo-dev@incubator.apache.org Subject: Re: Logo of AOO in SVG? On 29 April 2012 23:27, Claudio Filho filh...@gmail.com wrote: Hi 2012/4/29 Ian Lynch ianrly...@gmail.com: Just to say I have uploaded more logo candidates including with the text for 3.4 Release Candidate 1 and some versions incorporating the Apache feather. Any comments improvements, redesigns welcome. Ian, have some wrong thing in
Re: [Spi-private] OpenOffice funds
Louis OpenOffice.org was using SPI for aspects of fund raising and money management. With the transfer of the code to Apache and the development of a new community around Apache OpenOffice, as it is now called, there is no need for SPI's services. Why is there no Apache OpenOffice listed on http://projects.apache.org/indexes/alpha.html#O ? I suspect the donations held at SPI are earmarked for OpenOffice.org so can the Apache Software Foundation handle that and avoid using the funds for foundation-level costs? It's not clear to me from http://www.apache.org/foundation/contributing.html Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
Re: Distributing AOO 3.4: The 22 things we need to do before we announce
On Mon, Apr 30, 2012 at 4:53 AM, Jürgen Schmidt jogischm...@googlemail.com wrote: On 4/28/12 1:40 AM, Rob Weir wrote: On Fri, Apr 27, 2012 at 10:41 AM, Rob Weirrobw...@apache.org wrote: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Please review this task list and see if anything is missing. It would be great to confirm that this list is complete and to have a volunteer's name listed against each one of these tasks. I added a new task, now #2. Once we have the final files approved we should whitelist' them with Symantec, so users will get fewer false-hits from anti-virus. https://submit.symantec.com/whitelist/isv/new/ Among the information they need is URL and SHA256 hash. It looks like each language will need to be submitted separately. Ok we have currently sha1 and sha512 checksums, should we skip one of them in favor of sha256? Maybe we can simplify this in future release, but in this case we did vote on a release with sha1 and sha512, so I think we need to keep those. And in the future we probably solve this with code signing. But for 3.4 Symantec allows us to provide a sha256 instead of code signing. This signature does not need to be in the distribution. It is only uploaded to Symantec on their whitelisting form. I don't know if it matters, but they recommend using this tool: http://technet.microsoft.com/en-us/sysinternals/bb897441.aspx -Rob I'm assuming only Windows. Or is Symantec used on MacOS as well? Symantec is used on Mac as well Juergen -Rob Note the additional complexity caused by having hard-coded download logic on the various NL pages. -Rob
Re: After AOO 3.4?
On Mon, Apr 30, 2012 at 12:55 AM, Juergen Schmidt jogischm...@googlemail.com wrote: On Sunday, 29. April 2012 at 21:10, Pedro Giffuni wrote: --- Sab 28/4/12, Rob Weir robw...@apache.org ha scritto: ... All in all, I think we should focus on stability and not on features. What I am meaning here is that our users should not expect false promises like adding an import Visio documents feature that simply doesn't work. Of course features from Symphony are considered already pretty stable. So these (to me) sound more like items for a 3.5 than a 3.4.1. I think it all depends on how fast we plan to release 4.0. It looks likely that merging Symophony may be easy for the IBM guys, since symphony already updated theit base OOo, so a release may be fast and the 3.x branch may be short lived. (I don't know for sure though). I think a 3.x branch does make sense in any case but the rule should be clear: no direct commits to the stable branch: in general all changes go first to the trunk and are later merged. I don't think so, I would do it exactly in the other direction. Fixes for critical issues or issues that are assigned for a 3.4.1 should be fixed on the related stable branch and also merged into trunk. I thought Armin ran into some performance-related issues with merging. Do we know what direction that was, and what we need to do to avoid this problem in the future? -Rob But we can discuss if we want code reviews for fixes going into the stable branch before they are committed. Juergen Pedro.
Re: [Spi-private] OpenOffice funds
On 30 April 2012 09:27, MJ Ray m...@phonecoop.coop wrote: Louis I'm jumping in and speaking as a mentor of AOO and ASF VP of Community Development. OpenOffice.org was using SPI for aspects of fund raising and money management. With the transfer of the code to Apache and the development of a new community around Apache OpenOffice, as it is now called, there is no need for SPI's services. Why is there no Apache OpenOffice listed on http://projects.apache.org/indexes/alpha.html#O ? That page lists Apache Top Level Projects. Apache OpenOffice is not yet a Top Level Project, it is still in the incubator and listed at http://incubator.apache.org/ The Apache OpenOffice site is at http://incubator.apache.org/openofficeorg/ and the http://www.openoffice.org/ is now on ASF hardware. In order to become a Top Level Project AOO needs to release a version of OpenOffice which is licensed under an Apache license and have a community that is sufficiently divers to ensure long term viability. Diversity is not a problem and the first Apache licensed release is imminent. I suspect the donations held at SPI are earmarked for OpenOffice.org so can the Apache Software Foundation handle that and avoid using the funds for foundation-level costs? The money will be used for the exclusive benefit of the OpenOffice.org project (now Apache OpenOffice) for purposes described on the original collection page. Please note that this is an exception to the normal policy within the ASF, which does not generally accept targeted donations. However, since this money was donated for a specific set of uses the ASF will honour this and make the money available to the AOO project as a discretionary budget for uses defined by the SPI collection page. For more information on this please see the mail sent by Wolf Halton to treasu...@spi-inc.org on 19 March 2012 (subject monies collected for OpenOffice.org) and copied to bo...@spi-inc.org by Michael Schultheiss on the same day. Specifically: we [the AOO project] have a project-wide consensus that any funds SPI has collected be used for developer travel and event planning. If we can piggyback on larger ASF events, this money can go a long way. Though the original information page said the monies collected might also be used to pay application developers, this use is off the table because ASF rules specifically prohibit their paying for development. Please note that the final stages of approval for the appropriate handling of this money is in progress at the ASF (I speak as a Member of the foundation, but not as a member of the Fundraising committee). We will not request final transfer until such approval has been confirmed by the Fundraising committee. However, I believe this to be a matter of process at this point. I'll leave it to the AOO community to address further issues and continue making arrangements, but if you require an official statement from the ASF please don't hesitate to ask. Ross It's not clear to me from http://www.apache.org/foundation/contributing.html Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all operates, it took me forever to fix this one aspect. I could have not bothered with this
Re: After AOO 3.4?
On 30.04.2012 14:35, Rob Weir wrote: On Mon, Apr 30, 2012 at 12:55 AM, Juergen Schmidt jogischm...@googlemail.com wrote: [..] I don't think so, I would do it exactly in the other direction. Fixes for critical issues or issues that are assigned for a 3.4.1 should be fixed on the related stable branch and also merged into trunk. I thought Armin ran into some performance-related issues with merging. Do we know what direction that was, and what we need to do to avoid this problem in the future? It happened due to having a branch for aw080 before quite some header changes and file attribute changes were made, plus some exchange and movement of binary blobs. This should not happen with working branches in the future as long as the changes to the source will not get extreme (as in this case). Anyways, there are two distinct branch usages here: (1) What I called 'work branch': Something branched from trunk, but with the medium or long time goal to reintegrate to trunk. This makes resyncing with trunk necessary; thus may be expensive with big changes on trunk (2) Release branches: These are here to 'freeze' a release and to continue development of a bugfixed version (no features) .e.g. a 3.4.1 from a 3.4. These are from the principle not intended to be merged back to trunk ever, thus no danger to run in performance issues here. -Rob But we can discuss if we want code reviews for fixes going into the stable branch before they are committed. Juergen Pedro. Sincerely, Armin -- ALG
Re: After AOO 3.4?
I don't think so, I would do it exactly in the other direction. Fixes for critical issues or issues that are assigned for a 3.4.1 should be fixed on the related stable branch and also merged into trunk. +1 I thought Armin ran into some performance-related issues with merging. Do we know what direction that was, and what we need to do to avoid this problem in the future? The performance problem happened when committing a branch that was rebased to a revision which contained a massive cleanup regarding the executable flags of the files contained in the AOO repository. To SVN the commit almost looked like the import of a massive code base since so many files were touched by the cleanup. I don't think the approach to do critical fixes on the release branch and merging them into trunk will ever trigger such a scenario as above. Herbert
Re: [RELEASE]: proposed directory structure on dist
On 4/30/12 9:12 AM, Jürgen Schmidt wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/... .../dist/incubator/ooo/files/3.4.0/localized/hu/... .../dist/incubator/ooo/files/3.4.0/localized/it/... .../dist/incubator/ooo/files/3.4.0/localized/ja/... .../dist/incubator/ooo/files/3.4.0/localized/nl/... .../dist/incubator/ooo/files/3.4.0/localized/pt-BR/... .../dist/incubator/ooo/files/3.4.0/localized/ru/... .../dist/incubator/ooo/files/3.4.0/localized/zh-CN/...
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On 4/30/12 2:53 PM, Rob Weir wrote: On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenkkay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all operates, it took me forever to fix this one aspect. I could have not bothered with this but well, I didn't
AOO nears graduation
I just published a piece on ComputerWorld titled Is OpenOffice.org an Apache project yet? [1] In this piece I examine what the common behaviours found in a typical Apache Top Level Project are and comment on how AOO is performing in these respects. When reading this peice you must bear in mind that I am only one mentor and others might have different opinions. Nevertheless, I'm sufficiently confident in my position on this to state them publicly. Well done AOO Ross [1] http://blogs.computerworlduk.com/apache-asserts/2012/04/is-openofficeorg-an-apache-project-yet/index.htm -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: AOO nears graduation
Thanks Ross, I think we can take up this topic once the 3.4 release cycle is complete and we've flattened any issues that arise from it. On Mon, Apr 30, 2012 at 11:14 AM, Ross Gardler rgard...@opendirective.comwrote: I just published a piece on ComputerWorld titled Is OpenOffice.org an Apache project yet? [1] In this piece I examine what the common behaviours found in a typical Apache Top Level Project are and comment on how AOO is performing in these respects. When reading this peice you must bear in mind that I am only one mentor and others might have different opinions. Nevertheless, I'm sufficiently confident in my position on this to state them publicly. Well done AOO Ross [1] http://blogs.computerworlduk.com/apache-asserts/2012/04/is-openofficeorg-an-apache-project-yet/index.htm -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On Mon, Apr 30, 2012 at 2:54 AM, RGB ES rgb.m...@gmail.com wrote: 2012/4/30 Kay Schenk kay.sch...@gmail.com: Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all operates, it took me forever to fix this one aspect. I could have not bothered with this but well, I didn't want to lead folks astray with a not found -- so they will now get sent to other.html. So, please test with what you've got and I hope for ALL platforms that we do support, you get a link that looks to be correct. ps. I'm assuming that we will house the actual source artifact from Apache and this will show up in other.html as well when someone provides this information. Going to that page, I enter on a loop of pop-ups: the first one says schema:aoo_incubating, the second one Platform:linux 64-bit and then this message: myURLlink :a href= http://sourceforge.net/projects/openofficeorg.mirror/files/localized/es/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86-64_install-rpm_es.tar.gz/download title = http://sourceforge.net/projects/openofficeorg.mirror/files/localized/es/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86-64_install-rpm_es.tar.gz/download Then everything starts again with some variants (a message saying hasMirroLink:true) and after another loop I finally land on the download page. This happens with firefox 12 and konqueror 4.8.2. yes, this is what happens ... it is all right. All these will be removed -- very confusing I agree. Not to worry... and sorry for the amount of code spatter. Regards Ricardo -- MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On Mon, Apr 30, 2012 at 5:53 AM, Rob Weir robw...@apache.org wrote: On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219 http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/ http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today*
Re: [RELEASE]: proposed directory structure on dist
On Mon, Apr 30, 2012 at 9:24 AM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, Apr 30, 2012 at 12:12 AM, Jürgen Schmidt jogischm...@googlemail.com wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischmidt@**googlemail.comjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/incubator/ooohttps://www.apache.org/dist/**incubator/ooo https://www.**apache.org/dist/incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/... 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/**projects/openofficeorg.mirror/**files/http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.**0/stable /dist/incubator/ooo/files/3.4.**0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/**3.4.0/stable/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/**3.4.0/stable/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_en-US.dmg.**asc .../dist/incubator/ooo/files/**3.4.0/stable/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_en-US.dmg.**md5 .../dist/incubator/ooo/files/**3.4.0/stable/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_en-US.dmg.**sha1 .../dist/incubator/ooo/files/**3.4.0/stable/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_en-US.dmg.**sha512 .../dist/incubator/ooo/files/**3.4.0/stable/... .../dist/incubator/ooo/files/**3.4.0/localized/de/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/**3.4.0/localized/de/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/**3.4.0/localized/de/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/**3.4.0/localized/de/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/**3.4.0/localized/de/Apache_** OpenOffice_incubating_3.4.0_**MacOS_x86_install_de.dmg.**sha512 .../dist/incubator/ooo/files/**3.4.0/localized/de/... .../dist/incubator/ooo/files/**3.4.0/localized/ar/... .../dist/incubator/ooo/files/**3.4.0/localized/cs/... .../dist/incubator/ooo/files/**3.4.0/localized/en-GB/...
Re: [RELEASE]: proposed directory structure on dist
On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenk kay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? -Rob
Re: [RELEASE]: proposed directory structure on dist
On Mon, Apr 30, 2012 at 10:00 AM, Rob Weir robw...@apache.org wrote: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenk kay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? -Rob Well, for me anyway (I can't address the machinations of setting this up for actual upload), right now it's a matter of getting what we need to do to work in the next day, hopefully. I have other commitments later in the week, and well, I would like to get to a conclusion on this. This will also effect the links in the new other.html as well. (I think given all this I need to split other.html from the new download/index.html and let someone else work on other. I'm kind of getting into a time crunch.) This being said, maybe the version-centric approach Jurgen has suggested from his most recent post and Marcus suggested (I think) makes sense... Again, since all the scripting will be directed to SF, I just need to know what we're doing. The change to make this happen is not horrendous, butthings need to be tracked down in several places. -- MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette
Re: [RELEASE]: proposed directory structure on dist
On Apr 30, 2012, at 6:29 AM, Jürgen Schmidt wrote: On 4/30/12 9:12 AM, Jürgen Schmidt wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/... .../dist/incubator/ooo/files/3.4.0/localized/hu/... .../dist/incubator/ooo/files/3.4.0/localized/it/... .../dist/incubator/ooo/files/3.4.0/localized/ja/...
Re: [RELEASE]: proposed directory structure on dist
On Mon, Apr 30, 2012 at 1:25 PM, Dave Fisher dave2w...@comcast.net wrote: On Apr 30, 2012, at 6:29 AM, Jürgen Schmidt wrote: On 4/30/12 9:12 AM, Jürgen Schmidt wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/... .../dist/incubator/ooo/files/3.4.0/localized/hu/... .../dist/incubator/ooo/files/3.4.0/localized/it/... .../dist/incubator/ooo/files/3.4.0/localized/ja/...
Re: Seeking fun facts about AOO 3.4
On 4/29/2012 3:44 PM, Rob Weir wrote: I'm looking for interesting factoids about AOO 3.4 and the process that got us here. We started on June 13, 2011. What have we done? For example, we've had 17,340 posts to this mailing list We've fixed 291 BZ issues, 161 of which were reported since we started at Apache. We've elected 25 committers. Does anyone have other numbers? 355 automated builds on buildbot * linux - 207 * windows - 148 For example, how many dev snapshots have we had? How many forum messages have we had in this period? How many unique users have we supported? How many words of translation have we added? How many source files have been edited? -Rob
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On Apr 30, 2012, at 9:08 AM, Kay Schenk wrote: On Mon, Apr 30, 2012 at 5:53 AM, Rob Weir robw...@apache.org wrote: On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219 http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/ http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links
Draft blog post: Avoiding OpenOffice Download Scams
https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. -Rob
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all operates, it took me forever to fix this one aspect. I could have not bothered with this but well, I didn't want to lead folks astray with a not found -- so they will now get
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Am 04/30/2012 06:08 PM, schrieb Kay Schenk: On Mon, Apr 30, 2012 at 5:53 AM, Rob Weirrobw...@apache.org wrote: On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenkkay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219 http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/ http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just today* that we don't want to continue to generate links for OSes we no longer support now, like Sun's retinue, and for some reason because of how this all
Re: [RELEASE]: proposed directory structure on dist
Am 04/30/2012 07:21 PM, schrieb Kay Schenk: On Mon, Apr 30, 2012 at 10:00 AM, Rob Weirrobw...@apache.org wrote: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenkkay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? -Rob Well, for me anyway (I can't address the machinations of setting this up for actual upload), right now it's a matter of getting what we need to do to work in the next day, hopefully. I have other commitments later in the week, and well, I would like to get to a conclusion on this. This will also effect the links in the new other.html as well. (I think given all this I need to split other.html from the new download/index.html and let someone else work on other. I'm kind of getting into a time crunch.) I can take this over. Once the download links are working in general, it's just a big work of search replace, and to delete the languages we do not support yet, and the same for the platforms, and ... ;-) Marcus This being said, maybe the version-centric approach Jurgen has suggested from his most recent post and Marcus suggested (I think) makes sense... Again, since all the scripting will be directed to SF, I just need to know what we're doing. The change to make this happen is not horrendous, butthings need to be tracked down in several places.
rollApp launches free beta OpenOffice on iPad cloud-service - Press Release - Digital Journal
Nice mention of Apache OO in this press release by and about rollApp. In the recent ODF plugfest, I featured rollApp's deployment of OpenOffice as an immediate solution to using an ODF editor on tablets such as the iPad. There has been, as we all know, and as I have repeatedly urged and tried to organize the development of, a call for an ODF editor (read: OO on the tablet) for a long time….. In the meanwhile, and this really does work…. http://www.digitaljournal.com/pr/670497 --- Louis Suárez-Potts, PhD President, Age of Peers Skype: louisiam GTalk: lui...@gmail.com Twitter: @luispo Blog1: http://luispo.wordpress.com/ Blog2: http://ooo-speak.blogspot.com/ LinkedIn: http://ca.linkedin.com/in/luispo
Re: Draft blog post: Avoiding OpenOffice Download Scams
On 30 April 2012 19:10, Rob Weir robw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? -Rob
Re: After AOO 3.4?
On 04/29/12 23:55, Juergen Schmidt wrote: ... I think it all depends on how fast we plan to release 4.0. It looks likely that merging Symophony may be easy for the IBM guys, since symphony already updated theit base OOo, so a release may be fast and the 3.x branch may be short lived. (I don't know for sure though). One thing here that I should've mentioned is that it's rather inconvenient that we will not have the symphony history. It would've made it much easier to merge features. I think a 3.x branch does make sense in any case but the rule should be clear: no direct commits to the stable branch: in general all changes go first to the trunk and are later merged. I don't think so, I would do it exactly in the other direction. Fixes for critical issues or issues that are assigned for a 3.4.1 should be fixed on the related stable branch and also merged into trunk. Well, developing an OS is different than developing an Office Suite but direct commits to the stable branch in my favorite OSS project are prohibited except for specific cases (like if the code disappeared from trunk already) for good reasons. For one thing we are many committers and it's easy to lose track if the change was merged to the trunk so it is a good policy to ensure consistency in the different versions. It also keeps the SVN merge properties consistent. I am by no means a SVN expert but it's likely that using svn merge, instead of svn commit in branches is the recommended practice. Just my $0.02, Pedro.
Re: [RELEASE]: proposed directory structure on dist
On Apr 30, 2012, at 10:44 AM, Rob Weir wrote: On Mon, Apr 30, 2012 at 1:25 PM, Dave Fisher dave2w...@comcast.net wrote: On Apr 30, 2012, at 6:29 AM, Jürgen Schmidt wrote: On 4/30/12 9:12 AM, Jürgen Schmidt wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/... .../dist/incubator/ooo/files/3.4.0/localized/hu/...
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. I've tested the following: 1. Linux with Firefox -- Linux x86-64 RPM de -- the text in the pop-ups makes sense -- OK 2. Windows XP with MSIE -- error -- the detailed error message says: Line: 104 Char: 1 Error: Identifier, string or number expected Code: 0 URL: http://ooo-site.staging.apache.org/download/test/index_new_dl.html Line: 286 Char: 2
Re: Draft blog post: Avoiding OpenOffice Download Scams
On Mon, Apr 30, 2012 at 2:27 PM, sebb seb...@gmail.com wrote: On 30 April 2012 19:10, Rob Weir robw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. Yes. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? It is a hyperlink so in most cases it will just launch their email. i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? It is for the user's safety. Otherwise I can be sure we'll get their home phone numbers and credit card numbers posted to the public list. Remember, we're talking about the very end users who have already been scammed once. So we already know that they are not the most careful web users. Of course, we don't need to collect their reports if we don't want to. But they send them already. This particular one was sent to our security list. -Rob -Rob
Re: [RELEASE]: proposed directory structure on dist
Am 04/30/2012 07:00 PM, schrieb Rob Weir: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenkkay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Honestly spoken, I don't know if this will work. Of course it could be easy and fast to think about a directory structure that will work also for a AOO 5.0 release. However, I doubt that we will have the time to make the DL logic work this way, too. As I've no idea how close we are from the first public download of AOO 3.4 I wouldn't do bigger changes now. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? The DL logic for 3.4.1 can be the same as for 3.4.0. There shouldn't be big changes. For further releases see above. Juergen is already OK to setup the structure like it was in the old project, so that the need changes to the DL logic is minimal. To setup a new structure that makes maybe more sense can be done later for a release after 3.4.x. my 2 ct Marcus
Re: Draft blog post: Avoiding OpenOffice Download Scams
On 30 April 2012 19:41, Rob Weir robw...@apache.org wrote: On Mon, Apr 30, 2012 at 2:27 PM, sebb seb...@gmail.com wrote: On 30 April 2012 19:10, Rob Weir robw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. Yes. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? It is a hyperlink so in most cases it will just launch their email. Sorry, was not clear - I meant that they might have difficulty de-mangling the anti-spam measure. Maybe it would be better to direct them to a web-page that can give more information on reporting such problems. That page could be updated as necessary (e.g. when the e-mail address changes on graduation). Or the page could use plain-text mail links to temporary mail aliases that are rotated (would need to involve infra on that). Having a separate reporting page would be much more flexible; just make sure that its URL does not change (or a redirect is used). i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? It is for the user's safety. Otherwise I can be sure we'll get their home phone numbers and credit card numbers posted to the public list. Remember, we're talking about the very end users who have already been scammed once. So we already know that they are not the most careful web users. OK, understood. Of course, we don't need to collect their reports if we don't want to. But they send them already. This particular one was sent to our security list. -Rob -Rob
Re: [CONF] Apache OpenOffice Community AOO 3.4 Distribution Tasks
@Kay: I've splitted the work for download/index.html and download/other.html. Hope you don't mind. Marcus Am 04/30/2012 08:59 PM, schrieb conflue...@apache.org: Space: Apache OpenOffice Community (https://cwiki.apache.org/confluence/display/OOOUSERS) Page: AOO 3.4 Distribution Tasks (https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks) Edited by Marcus Lange: - The following tasks need to be done to support the distribution of AOO 3.4 once its release is approved. ... # Update download/index.html pages to SourceForge download locations for AOO 3.4. Establish a test period for these new links. Test with various user agent configurations and languages. (*kay*, in progress) # Update download/other.html pages to SourceForge download locations for AOO 3.4. Establish a test period for these new links. Test with various user agent configurations and languages. (*kay*, *marcus*) ...
Re: Draft blog post: Avoiding OpenOffice Download Scams
Am 04/30/2012 08:57 PM, schrieb sebb: On 30 April 2012 19:41, Rob Weirrobw...@apache.org wrote: On Mon, Apr 30, 2012 at 2:27 PM, sebbseb...@gmail.com wrote: On 30 April 2012 19:10, Rob Weirrobw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. Yes. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? It is a hyperlink so in most cases it will just launch their email. Sorry, was not clear - I meant that they might have difficulty de-mangling the anti-spam measure. Maybe it would be better to direct them to a web-page that can give more information on reporting such problems. That page could be updated as necessary (e.g. when the e-mail address changes on graduation). The German community of the old OOo project has written something very similar: http://www.openoffice.org/de/abgezockt/ It's to inform users that OOo is free of change, they shouldn't pay anything for it, where to download the original software, etc. Of course it's currently only in German ;-( but maybe it makes sense to translate it into English and to go on with using it. Marcus Or the page could use plain-text mail links to temporary mail aliases that are rotated (would need to involve infra on that). Having a separate reporting page would be much more flexible; just make sure that its URL does not change (or a redirect is used). i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? It is for the user's safety. Otherwise I can be sure we'll get their home phone numbers and credit card numbers posted to the public list. Remember, we're talking about the very end users who have already been scammed once. So we already know that they are not the most careful web users. OK, understood. Of course, we don't need to collect their reports if we don't want to. But they send them already. This particular one was sent to our security list. -Rob -Rob
Volunteers needed: To update NL download pages later this week
The following tasks are on the wiki and need owners: Manually update the downloads from the Arabic NL homepage Manually update the downloads from the Czech NL homepage Manually update the downloads from the German NL homepage Manually update the downloads from the Spanish NL homepage Manually update the downloads from the French NL homepage Manually update the downloads from the Hungarian NL homepage Manually update the downloads from the Galacian NL homepage Manually update the downloads from the Italian NL homepage and subpages (pescetti) Manually update the downloads from the Japanese NL homepage Manually update the downloads from the Dutch NL homepage Manually update the downloads from the Brazilian NL homepage Manually update the downloads from the Russian NL homepage Manually update the downloads from the Simplified Chinese NL homepage Manually update the downloads from the Traditional Chinese NL homepage https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Only one of them has an owner (Thanks, Andrea!) What needs to be done? We need someone to review these NL pages and identify what needs to be changed to support the AOO 3..4 release. Changes to consider: 1) Branding changes (OpenOffice.org - Apache OpenOffice) 2) Updates to download location, for the 3.4 releases instead of the 3.3 release 3) References to the old LGPL license need to be changed to Apache 2.0 License 4) References to old NLC email addresses, marketing leads, etc., need to be replaced by the new Apache email lists. 5) Other similar changes. You don't need to do a complete rewrite of the pages. But we should refresh the page with information on the AOO 3.4 release. Timeline looks like this: -- Wednesday May 2nd -- Vote ends on approving the 3.4 release -- Thursday-Friday -- Update the mirrors with the release, test the new download websites. -- Over the weekend, additional website updates and testing -- Monday or Tuesday, if everything is working well, then we make public announcement So ideally we would have the NL website updates done at the end of this week. However, we should not make them be live on the production server until after the mirrors are populated. Maybe easiest way to coordinate is to submit patches for the changes into BZ? Any other ideas? Any volunteers? -Rob
Re: [RELEASE]: proposed directory structure on dist
On Mon, Apr 30, 2012 at 8:47 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 04/30/2012 07:00 PM, schrieb Rob Weir: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenkkay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Honestly spoken, I don't know if this will work. Of course it could be easy and fast to think about a directory structure that will work also for a AOO 5.0 release. However, I doubt that we will have the time to make the DL logic work this way, too. As I've no idea how close we are from the first public download of AOO 3.4 I wouldn't do bigger changes now. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? The DL logic for 3.4.1 can be the same as for 3.4.0. There shouldn't be big changes. For further releases see above. Juergen is already OK to setup the structure like it was in the old project, so that the need changes to the DL logic is minimal. It seems the easiest way to go to me too. Roberto To setup a new structure that makes maybe more sense can be done later for a release after 3.4.x. my 2 ct Marcus This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
Re: [Spi-private] OpenOffice funds
Thanks, Michael! Best Louis On 2012-04-30, at 15:30 , Michael Schultheiss wrote: Louis Suárez-Potts wrote: Hi All, First I'm cc'ing the public list ooo-dev@apache. Communication using that list is public. Second, and the point of this communication: OpenOffice.org was using SPI for aspects of fund raising and money management. With the transfer of the code to Apache and the development of a new community around Apache OpenOffice, as it is now called, there is no need for SPI's services. These were good, and as the representative from OOo to SPI, I thank you for them. Biut with the Apache fund management system, not only do we not need SPI but having it as the manager of funds accrued prior to the transfer to Apache only complicates matters. We would like to to have those funds transferred via Wire to Apache. I can (or others who know more) supply the relevant bank information for that. I've sent a check for the current OO.org balance to the address listed at http://apache.org/foundation/contributing.html I overlooked the desire to wire the money when I initially read this message. Hopefully the different payment method won't be too much of a hassle. I, and others, would like to sort this out soon, as having funds that can be used to further develop the project split among groups, however friendly, is counterproductive. The check should be received by 2012-05-04. -- Michael Schultheiss E-mail: schul...@spi-inc.org
Re: New group Apache OpenOffice on XING
I have a Xing account, but of course, do not speak German. I'm happy to be one of the moderators. On Mon, Apr 30, 2012 at 5:43 AM, Jürgen Schmidt jogischm...@googlemail.comwrote: Hi, I have created a new group Apache OpenOffice on XING that is under control of the project. https://www.xing.com/net/**pri344752x/aoohttps://www.xing.com/net/pri344752x/aoo PPMC members with XING account who have interest to help this group as co-moderator please let me know and I will add you. The former group OpenOffice.org is still present but I failed so far to convince the moderator of this group to allow further moderators from the PMC. But I will continue to get or at least share control over this group by the PPMC. Juergen
Re: Volunteers needed: To update NL download pages later this week
Manually update the downloads from the French NL homepage Any volunteers? I take this one
Re: Volunteers needed: To update NL download pages later this week
Hi Rob, 2012.04.30 21:41 időpontban Rob Weir ezt írta: The following tasks are on the wiki and need owners: Manually update the downloads from the Arabic NL homepage Manually update the downloads from the Czech NL homepage Manually update the downloads from the German NL homepage Manually update the downloads from the Spanish NL homepage Manually update the downloads from the French NL homepage Manually update the downloads from the Hungarian NL homepage I volunteer for Hungarian page, modified wiki Manually update the downloads from the Galacian NL homepage Manually update the downloads from the Italian NL homepage and subpages (pescetti) Manually update the downloads from the Japanese NL homepage Manually update the downloads from the Dutch NL homepage Manually update the downloads from the Brazilian NL homepage Manually update the downloads from the Russian NL homepage Manually update the downloads from the Simplified Chinese NL homepage Manually update the downloads from the Traditional Chinese NL homepage https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Only one of them has an owner (Thanks, Andrea!) What needs to be done? We need someone to review these NL pages and identify what needs to be changed to support the AOO 3..4 release. Changes to consider: 1) Branding changes (OpenOffice.org - Apache OpenOffice) 2) Updates to download location, for the 3.4 releases instead of the 3.3 release 3) References to the old LGPL license need to be changed to Apache 2.0 License 4) References to old NLC email addresses, marketing leads, etc., need to be replaced by the new Apache email lists. 5) Other similar changes. You don't need to do a complete rewrite of the pages. But we should refresh the page with information on the AOO 3.4 release. Timeline looks like this: -- Wednesday May 2nd -- Vote ends on approving the 3.4 release -- Thursday-Friday -- Update the mirrors with the release, test the new download websites. -- Over the weekend, additional website updates and testing -- Monday or Tuesday, if everything is working well, then we make public announcement So ideally we would have the NL website updates done at the end of this week. However, we should not make them be live on the production server until after the mirrors are populated. Maybe easiest way to coordinate is to submit patches for the changes into BZ? Any other ideas? My problem with the downloaded files from svn, which one needs to be changed? My problem is that the old Hungarian OOo site contains files which was manually customized, the content and layout not match to the English site. How can I proceed, I download En site from svn and translate it, and upload to Hungarian part of svn? How can I check my work, I'm an only Hungarian in PPMC? Zoltan Any volunteers? -Rob
Re: [Spi-private] OpenOffice funds
Ross Gardler wrote: Please note that the final stages of approval for the appropriate handling of this money is in progress at the ASF (I speak as a Member of the foundation, but not as a member of the Fundraising committee). We will not request final transfer until such approval has been confirmed by the Fundraising committee. However, I believe this to be a matter of process at this point. Given this additional information, I've cancelled the scheduled check payment of the OpenOffice.org funds to the ASF. Once the ASF Fundraising committee finishes its approval process I can re-initiate the transfer. The easiest method for SPI to transfer the funds is a check but alternate methods of payment are also available if preferred. -- Michael Schultheiss E-mail: schul...@spi-inc.org signature.asc Description: Digital signature
Re: [Spi-private] OpenOffice funds
Louis Suárez-Potts wrote: Hi All, First I'm cc'ing the public list ooo-dev@apache. Communication using that list is public. Second, and the point of this communication: OpenOffice.org was using SPI for aspects of fund raising and money management. With the transfer of the code to Apache and the development of a new community around Apache OpenOffice, as it is now called, there is no need for SPI's services. These were good, and as the representative from OOo to SPI, I thank you for them. Biut with the Apache fund management system, not only do we not need SPI but having it as the manager of funds accrued prior to the transfer to Apache only complicates matters. We would like to to have those funds transferred via Wire to Apache. I can (or others who know more) supply the relevant bank information for that. I've sent a check for the current OO.org balance to the address listed at http://apache.org/foundation/contributing.html I overlooked the desire to wire the money when I initially read this message. Hopefully the different payment method won't be too much of a hassle. I, and others, would like to sort this out soon, as having funds that can be used to further develop the project split among groups, however friendly, is counterproductive. The check should be received by 2012-05-04. -- Michael Schultheiss E-mail: schul...@spi-inc.org signature.asc Description: Digital signature
ooo-site/license .. getting rid of the references to category-x.
Hello; Checking the licenses in the website: http://www.openoffice.org/licenses/ I will be getting rid of the GPL and LGPL. I will leave some old stuff (OCA, SCA, PDL) just for reference. ~/Documents/ooo-licenses% svn status D gpl_license.html D lgpl_license.html D newlicense2008.html Having those licenses directly in our site can lead to confusions: if we really need to refer to them, like for the legacy versions, we can use links to the FSF directly. Although removing them may cause broken links I think it's good to do those cleanups sooner rather than later. Of course, feel free to drop in if you have a better way to do the cleanup :). Pedro.
Re: [RELEASE]: proposed directory structure on dist
On 04/30/2012 11:31 AM, Dave Fisher wrote: On Apr 30, 2012, at 10:44 AM, Rob Weir wrote: On Mon, Apr 30, 2012 at 1:25 PM, Dave Fisher dave2w...@comcast.net wrote: On Apr 30, 2012, at 6:29 AM, Jürgen Schmidt wrote: On 4/30/12 9:12 AM, Jürgen Schmidt wrote: On 4/27/12 10:09 PM, Kay Schenk wrote: On 04/27/2012 12:47 PM, Marcus (OOo) wrote: Am 04/27/2012 09:34 PM, schrieb Dave Fisher: On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote: Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt: On 4/27/12 5:32 PM, Kay Schenk wrote: 2012/4/27 J�rgen Schmidtjogischm...@googlemail.com Hi, to be prepared for the upcoming release I plan to use the following directory structure on https://www.apache.org/dist/**incubator/ooohttps://www.apache.org/dist/incubator/ooo Existing 3.3 3.3/patches 3.3/patches/cve-2012-0037/... DATE KEYS New added: 3.4.0/source 3.4.0/windows/... 3.4.0/windows/languagepacks/..**. 3.4.0/macos/... 3.4.0/macos/languagepacks/... 3.4.0/linux-x86/... 3.4.0/linux-x86/languagepacks/**... 3.4.0/linux-x86-64/... 3.4.0/linux-x86-64/**languagepacks/... 16 languages: en-US ar cs de en-GB es fr gl hu it ja nl ru pr-BR zh-CN zh-TW Do we need to prepare or adapt the download page? Juergen Juergen-- This will considerably change the current logic being used. Is there some reason you don't want to use the existing setup of: root DL area/files/stable/3.4/... root DL area/files/localized/3.4/... see: http://sourceforge.net/projects/openofficeorg.mirror/files/ I had a look to other projects in the dist folder on Apache and looked what we already have. From my point of view the old structure doesn't really make too much sense. Why should we for example put the localized bit in separate directories when we have the language Id as part of the name? And we have only stable releases in the future. Ok we will have archives of older versions but that's it. Do we have the time to adapt it to the new structure. We should do it ow if possible. What do others think? It won't work because the DL logic is working the old way, and only this way. ;-) The old structure has everything in a single directory. The only separation is for en-US only (stable) and all other languages (localized). When we change the structure now where the builds are physicaly existing, then we have to adapt the complete logic, too, which is an effort that I cannot predict. So, the best solution is to keep the old separation and think about to change this with a new release. Then I would prefer to have every install file for a specific version in a single directory. This makes it the easiest way to assemble download links: Example: root-path/files/3.4.0/... root-path/files/3.4.1/... root-path/files/3.5.0/... ... We can only keep the most current version in Apache dist. All older versions go to the archive. Oh yes, right, then it's only one directory. Marcus right now -- especially with the desire to continue to serve up friendly dl logic in the new /download/3.3.0 directory, this is really and truly critical. Yes, it's true, given the Apache current release dictum, we will only have one directory setup -- /dist/incubator/ooo/files/3.4.0/stable /dist/incubator/ooo/files/3.4.0/localized ok that means I will upload the files in this way .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/stable/... .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1 .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512 .../dist/incubator/ooo/files/3.4.0/localized/de/... .../dist/incubator/ooo/files/3.4.0/localized/ar/... .../dist/incubator/ooo/files/3.4.0/localized/cs/... .../dist/incubator/ooo/files/3.4.0/localized/en-GB/... .../dist/incubator/ooo/files/3.4.0/localized/es/... .../dist/incubator/ooo/files/3.4.0/localized/fr/... .../dist/incubator/ooo/files/3.4.0/localized/gl/...
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On 04/30/2012 11:02 AM, Dave Fisher wrote: On Apr 30, 2012, at 9:08 AM, Kay Schenk wrote: On Mon, Apr 30, 2012 at 5:53 AM, Rob Weir robw...@apache.org wrote: On Sun, Apr 29, 2012 at 10:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219 http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/ http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. It suddenly dawned on me *just
Re: [RELEASE]: proposed directory structure on dist
On 04/30/2012 11:13 AM, Marcus (OOo) wrote: Am 04/30/2012 07:21 PM, schrieb Kay Schenk: On Mon, Apr 30, 2012 at 10:00 AM, Rob Weirrobw...@apache.org wrote: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenkkay.sch...@gmail.com wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. This is not something where it will be easier to clean up later. Thinking ahead, what do we do when we have a new release, like a 3.4.1? And what can we do now to make that future less painful? -Rob Well, for me anyway (I can't address the machinations of setting this up for actual upload), right now it's a matter of getting what we need to do to work in the next day, hopefully. I have other commitments later in the week, and well, I would like to get to a conclusion on this. This will also effect the links in the new other.html as well. (I think given all this I need to split other.html from the new download/index.html and let someone else work on other. I'm kind of getting into a time crunch.) I can take this over. Once the download links are working in general, it's just a big work of search replace, and to delete the languages we do not support yet, and the same for the platforms, and ... ;-) Marcus Marcus-- I will go ahead and finish with this piece, so no need. I know it's not all that big a deal...I just a bit too frustrated. But...I am going to separate (the new) other.html from the download/index.html business and maybe you could deal with that. Yeah--there's only a few of us that have messed with this stuff before, so somewhat mind-boggling. This being said, maybe the version-centric approach Jurgen has suggested from his most recent post and Marcus suggested (I think) makes sense... Again, since all the scripting will be directed to SF, I just need to know what we're doing. The change to make this happen is not horrendous, butthings need to be tracked down in several places. -- MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette
Re: [RELEASE]: proposed directory structure on dist
On 04/30/2012 12:47 PM, Roberto Galoppini wrote: On Mon, Apr 30, 2012 at 8:47 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 04/30/2012 07:00 PM, schrieb Rob Weir: On Mon, Apr 30, 2012 at 12:44 PM, Kay Schenkkay.sch...@gmail.com �wrote: snip Right now I have the DL friendly script setup to only use SF...which is setup in the old way. I don't think we'll be usign Apache for pre-build client downloads. So, I have a question -- who will be setting up the SF packs and will they just stick with the current structure on that system for DLs -- i.e. root/files/stable/version/ pack name and root/files/localized/language/version/pack name I'm hoping the answer is YES. Whatever we do, let's try to get a directory schem that works now and for AOO 3.4.1 and AOO 3.5 and for AOO 4.0, etc.. �This is not something where it will be easier to clean up later. Honestly spoken, I don't know if this will work. Of course it could be easy and fast to think about a directory structure that will work also for a AOO 5.0 release. However, I doubt that we will have the time to make the DL logic work this way, too. As I've no idea how close we are from the first public download of AOO 3.4 I wouldn't do bigger changes now. Thinking ahead, what do we do when we have a new release, like a 3.4.1? �And what can we do now to make that future less painful? The DL logic for 3.4.1 can be the same as for 3.4.0. There shouldn't be big changes. For further releases see above. Juergen is already OK to setup the structure like it was in the old project, so that the need changes to the DL logic is minimal. It seems the easiest way to go to me too. Roberto OK, I need some clarification here -- again. I am to understand by the above statements by Marcus and Roberto that the directory structure for 3.4 will be the same as it is for 3.3, but we will have a *different* structure on www.apache.org/dist? Also, OK, we just need some awareness. So -- can someone tell me what's what here. I CAN change the friendly scripts to go with the NEW (Apache) structure. In fact I'm going to work on THAT approach today (along with Rob's changes) and hopefully we'll be set for either instance. To setup a new structure that makes maybe more sense can be done later for a release after 3.4.x. my 2 ct Marcus This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. -- MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette
Re: [RELEASE] new DL test...needs review and comments, and probably correction
On 04/30/2012 11:37 AM, Marcus (OOo) wrote: Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. I've tested the following: 1. Linux with Firefox -- Linux x86-64 RPM de -- the text in the pop-ups makes sense -- OK 2. Windows XP with MSIE -- error -- the detailed error message says: Line: 104 Char: 1 Error:
Re: Volunteers needed: To update NL download pages later this week
On Mon, Apr 30, 2012 at 3:58 PM, Reizinger Zoltán zreizin...@hdsnet.hu wrote: Hi Rob, 2012.04.30 21:41 időpontban Rob Weir ezt írta: The following tasks are on the wiki and need owners: Manually update the downloads from the Arabic NL homepage Manually update the downloads from the Czech NL homepage Manually update the downloads from the German NL homepage Manually update the downloads from the Spanish NL homepage Manually update the downloads from the French NL homepage Manually update the downloads from the Hungarian NL homepage I volunteer for Hungarian page, modified wiki Manually update the downloads from the Galacian NL homepage Manually update the downloads from the Italian NL homepage and subpages (pescetti) Manually update the downloads from the Japanese NL homepage Manually update the downloads from the Dutch NL homepage Manually update the downloads from the Brazilian NL homepage Manually update the downloads from the Russian NL homepage Manually update the downloads from the Simplified Chinese NL homepage Manually update the downloads from the Traditional Chinese NL homepage https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Only one of them has an owner (Thanks, Andrea!) What needs to be done? We need someone to review these NL pages and identify what needs to be changed to support the AOO 3..4 release. Changes to consider: 1) Branding changes (OpenOffice.org - Apache OpenOffice) 2) Updates to download location, for the 3.4 releases instead of the 3.3 release 3) References to the old LGPL license need to be changed to Apache 2.0 License 4) References to old NLC email addresses, marketing leads, etc., need to be replaced by the new Apache email lists. 5) Other similar changes. You don't need to do a complete rewrite of the pages. But we should refresh the page with information on the AOO 3.4 release. Timeline looks like this: -- Wednesday May 2nd -- Vote ends on approving the 3.4 release -- Thursday-Friday -- Update the mirrors with the release, test the new download websites. -- Over the weekend, additional website updates and testing -- Monday or Tuesday, if everything is working well, then we make public announcement So ideally we would have the NL website updates done at the end of this week. However, we should not make them be live on the production server until after the mirrors are populated. Maybe easiest way to coordinate is to submit patches for the changes into BZ? Any other ideas? My problem with the downloaded files from svn, which one needs to be changed? Good question. For Hungarian, the files are here; https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/hu/ My problem is that the old Hungarian OOo site contains files which was manually customized, the content and layout not match to the English site. How can I proceed, I download En site from svn and translate it, and upload to Hungarian part of svn? You could do that. Dave has some instructions for doing that: http://markmail.org/message/pnqr7qmdzrvricxq If you have time to translate and create a new Hungarian homepage that would be ideal. But if we can just patch the old page to update it for AOO 3.4, that is good for now. How can I check my work, I'm an only Hungarian in PPMC? It depends on how familiar you are with command line tools like Subversion. If you are, then just check out the files, modify and commit the changes. Otherwise you could make all your changes locally, zip them up and attach then to a BZ issue and I (or another developer) can check them in. Thanks, -rob Zoltan Any volunteers? -Rob
Re: [RELEASE} a few DL questions...
On Fri, Apr 27, 2012 at 11:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:57 PM, Roberto Galoppini wrote: On Thu, Apr 26, 2012 at 9:04 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 1:47 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Thu, Apr 26, 2012 at 7:02 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 12:11 PM, Kay Schenkkay.sch...@gmail.com wrote: I've been working on a prototype of the DL button in the /download/test area given our discussions about split mirror setup for 3.4 etc. I have a �few more edits to do �before sending out a notification about final review (later today). But...I have a few questions for this release. * The DL scripts have a good amount of logic surrounding the naming/download of 3.2 and 3.1 releases-- the old naming schema. Since we won't be providing friendly DL buttons for these anymore, is it safe to pull this stuff out? * DL locations for Mac PPC and FreeBSD are as follows (excuse wrapping): var MIRROR_MAC_PPC_URL � � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/macosppc/;; var MIRROR_FREEBSD32_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86/;; var MIRROR_FREEBSD64_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86-64/;; Will this still be the case or will all versions be served from either Apache or SourceForge? The DL logic needs to be changed if this alternate URL is not used. I think the main download link should only provide links to official AOO releases. � We could have another section (maybe in other.html) where we can point to third party binaries and ports. �But we should have a disclaimer making it clear that these packages are not official releases. I also agree that we should not inter-mix 3.3 and 3.4 downloads. Another thing to consider is how we actually invoke the download. Right now we simply link to the SF site. �So after the download is done the user is left sitting at SF. �This is not ideal. � �I wonder whether it would be better to load the SF page in a new page, via target=_blank and then refresh our download.html to contribute.html so after the download is done, and the user closes the SF page, they are back in the openoffice website with a thanks for downloading messsage and followup info to engage the user in the community. Actually to avoid to open new pages we did modify the download page by adding all info previously available. We have been beta testing for over a week, and is now live. Hope this will remove the need to open new pages. Hi Roberto, So what we have today looks like this: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Win_x86_install-wJRE_en-US.exe/download After the download, on the left, are some boxes that contain all the info that we used to show to the user here: http://www.openoffice.org/download/contribute.html That is good, since it gives several different ways for the user to engage with the project, etc. However, it is less prominent than before and does require additional mouse clicks to navigate the different sections. � �I think it is less effective than what we had before. �For example, I'm seeing only 47 referrals since April 11th from SF to our Get Involved paged, the first link given. �We used to get hundreds of these from the old contribute.html page. I wonder if simpler would be better? �So instead of the pop-up page which I suggested before, and which is annoying for some users, maybe keep the SF as it is, but make the content simpler, with the aim of referring users back to contribute.html. So something like this: Thanks for downloading Apache OpenOffice, the free and open productivity suit. � We invite you to learn more about how to enhance your experience with OpenOffice, sign up to receive important notifications and learn how you can contribute to make the next version of OpenOffice even better. If we make it short and sweet like that, maybe even use some of the AOO graphical elements, then mayb we can improve the engagement? But I'm not a web UI/marketing expert. �Maybe someone has some other ideas. Working on it, it will be operative by next Monday. Roberto I love what SourceForge has done here by the way! Very nice! and very creative from the norm. Here we go, we put the suggested text with some links, plus the Participate icon. For example: http://sourceforge.net/projects/openofficeorg.mirror/files/localized/it/3.3.0/OOo_3.3.0_MacOS_x86_install_it.dmg/download Roberto -Rob Roberto -Rob Thanks for your time. -- MzK Well, life has a funny way of sneaking up on you �And life has a funny way of helping you out �Helping you out. � � � � � � � � � � � � � �-- Ironic, Alanis Morissette This e- mail message is intended
Re: Draft blog post: Avoiding OpenOffice Download Scams
On Mon, Apr 30, 2012 at 2:57 PM, sebb seb...@gmail.com wrote: On 30 April 2012 19:41, Rob Weir robw...@apache.org wrote: On Mon, Apr 30, 2012 at 2:27 PM, sebb seb...@gmail.com wrote: On 30 April 2012 19:10, Rob Weir robw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. Yes. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? It is a hyperlink so in most cases it will just launch their email. Sorry, was not clear - I meant that they might have difficulty de-mangling the anti-spam measure. Maybe it would be better to direct them to a web-page that can give more information on reporting such problems. That page could be updated as necessary (e.g. when the e-mail address changes on graduation). Or the page could use plain-text mail links to temporary mail aliases that are rotated (would need to involve infra on that). Having a separate reporting page would be much more flexible; just make sure that its URL does not change (or a redirect is used). Could do it via Bugzilla or JIRA as well, thought that does require account creation. But users tend to understand that this is a public database and are more careful with what they put there. i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? It is for the user's safety. Otherwise I can be sure we'll get their home phone numbers and credit card numbers posted to the public list. Remember, we're talking about the very end users who have already been scammed once. So we already know that they are not the most careful web users. OK, understood. Of course, we don't need to collect their reports if we don't want to. But they send them already. This particular one was sent to our security list. -Rob -Rob
Re: Draft blog post: Avoiding OpenOffice Download Scams
On Mon, Apr 30, 2012 at 3:52 PM, Louis Suárez-Potts lui...@gmail.com wrote: Hi On 2012-04-30, at 15:17 , Marcus (OOo) wrote: Am 04/30/2012 08:57 PM, schrieb sebb: On 30 April 2012 19:41, Rob Weirrobw...@apache.org wrote: On Mon, Apr 30, 2012 at 2:27 PM, sebbseb...@gmail.com wrote: On 30 April 2012 19:10, Rob Weirrobw...@apache.org wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few suggestions: The first paragraph should be quoted and / or in italic. s/the open source license/its open source license/ - there are several instances of this. Yes. If the end-user is likely to find the concept of MD5 difficult, won't they also find it difficult to use the provided e-mail link? It is a hyperlink so in most cases it will just launch their email. Sorry, was not clear - I meant that they might have difficulty de-mangling the anti-spam measure. Maybe it would be better to direct them to a web-page that can give more information on reporting such problems. That page could be updated as necessary (e.g. when the e-mail address changes on graduation). The German community of the old OOo project has written something very similar: http://www.openoffice.org/de/abgezockt/ It's to inform users that OOo is free of change, they shouldn't pay anything for it, where to download the original software, etc. Of course it's currently only in German ;-( but maybe it makes sense to translate it into English and to go on with using it. Actually the list associated with it worked fine, and I was also a recipient of it and after a while, an admin. Further, we also had other pages that served similar functions in English, though the German communities site was really the best. A simple email alias (or ideally wiki that is linked via Jscript or the like to a list) also works well. What we did in the months prior to transfer was collect urls of miscreants and then, when possible, proceed against them and defend the innocent. :-) So presumably that was abgezo...@openoffice.org? Was that a mailing list? Public or private? Or an email alias? A could see how an ASF-wide private mailing list could be useful for reporting trademark abuse, In the end, the PMC can collect such issues, but we would also need to circle back to Trademarks@ before we did anything. So maybe centralizing the collection of the reports would make sense? -Rob Cheers Louis Marcus Or the page could use plain-text mail links to temporary mail aliases that are rotated (would need to involve infra on that). Having a separate reporting page would be much more flexible; just make sure that its URL does not change (or a redirect is used). i.e. mailto:ooo-private-AT-incubator.apache-DOT-org Also, do such reports need to go to the private mailing list? It is for the user's safety. Otherwise I can be sure we'll get their home phone numbers and credit card numbers posted to the public list. Remember, we're talking about the very end users who have already been scammed once. So we already know that they are not the most careful web users. OK, understood. Of course, we don't need to collect their reports if we don't want to. But they send them already. This particular one was sent to our security list. -Rob -Rob
Re: [RELEASE} a few DL questions...
On Mon, Apr 30, 2012 at 5:48 PM, Roberto Galoppini rgalopp...@geek.net wrote: On Fri, Apr 27, 2012 at 11:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:57 PM, Roberto Galoppini wrote: On Thu, Apr 26, 2012 at 9:04 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 1:47 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Thu, Apr 26, 2012 at 7:02 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 12:11 PM, Kay Schenkkay.sch...@gmail.com wrote: I've been working on a prototype of the DL button in the /download/test area given our discussions about split mirror setup for 3.4 etc. I have a �few more edits to do �before sending out a notification about final review (later today). But...I have a few questions for this release. * The DL scripts have a good amount of logic surrounding the naming/download of 3.2 and 3.1 releases-- the old naming schema. Since we won't be providing friendly DL buttons for these anymore, is it safe to pull this stuff out? * DL locations for Mac PPC and FreeBSD are as follows (excuse wrapping): var MIRROR_MAC_PPC_URL � � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/macosppc/;; var MIRROR_FREEBSD32_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86/;; var MIRROR_FREEBSD64_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86-64/;; Will this still be the case or will all versions be served from either Apache or SourceForge? The DL logic needs to be changed if this alternate URL is not used. I think the main download link should only provide links to official AOO releases. � We could have another section (maybe in other.html) where we can point to third party binaries and ports. �But we should have a disclaimer making it clear that these packages are not official releases. I also agree that we should not inter-mix 3.3 and 3.4 downloads. Another thing to consider is how we actually invoke the download. Right now we simply link to the SF site. �So after the download is done the user is left sitting at SF. �This is not ideal. � �I wonder whether it would be better to load the SF page in a new page, via target=_blank and then refresh our download.html to contribute.html so after the download is done, and the user closes the SF page, they are back in the openoffice website with a thanks for downloading messsage and followup info to engage the user in the community. Actually to avoid to open new pages we did modify the download page by adding all info previously available. We have been beta testing for over a week, and is now live. Hope this will remove the need to open new pages. Hi Roberto, So what we have today looks like this: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Win_x86_install-wJRE_en-US.exe/download After the download, on the left, are some boxes that contain all the info that we used to show to the user here: http://www.openoffice.org/download/contribute.html That is good, since it gives several different ways for the user to engage with the project, etc. However, it is less prominent than before and does require additional mouse clicks to navigate the different sections. � �I think it is less effective than what we had before. �For example, I'm seeing only 47 referrals since April 11th from SF to our Get Involved paged, the first link given. �We used to get hundreds of these from the old contribute.html page. I wonder if simpler would be better? �So instead of the pop-up page which I suggested before, and which is annoying for some users, maybe keep the SF as it is, but make the content simpler, with the aim of referring users back to contribute.html. So something like this: Thanks for downloading Apache OpenOffice, the free and open productivity suit. � We invite you to learn more about how to enhance your experience with OpenOffice, sign up to receive important notifications and learn how you can contribute to make the next version of OpenOffice even better. If we make it short and sweet like that, maybe even use some of the AOO graphical elements, then mayb we can improve the engagement? But I'm not a web UI/marketing expert. �Maybe someone has some other ideas. Working on it, it will be operative by next Monday. Roberto I love what SourceForge has done here by the way! Very nice! and very creative from the norm. Here we go, we put the suggested text with some links, plus the Participate icon. For example: http://sourceforge.net/projects/openofficeorg.mirror/files/localized/it/3.3.0/OOo_3.3.0_MacOS_x86_install_it.dmg/download I like it. Thanks! -Rob Roberto -Rob Roberto -Rob Thanks for your time. -- MzK Well, life has a funny way of sneaking up on you �And life has a funny way of helping you out
Happy Birthday, OpenOffice!
Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! -Rob
Re: Happy Birthday, OpenOffice!
On 04/30/2012 03:08 PM, Rob Weir wrote: Anyone remember what happen 10 years ago today April 30th, 2002? now -- THIS is a fun little factoid! :) I started using openoffice.org in 2001, but I guess it was *before* the 1.0 release. http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! -Rob -- MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette
Re: [RELEASE} a few DL questions...
On 04/30/2012 02:48 PM, Roberto Galoppini wrote: On Fri, Apr 27, 2012 at 11:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:57 PM, Roberto Galoppini wrote: On Thu, Apr 26, 2012 at 9:04 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 1:47 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Thu, Apr 26, 2012 at 7:02 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 12:11 PM, Kay Schenkkay.sch...@gmail.com wrote: I've been working on a prototype of the DL button in the /download/test area given our discussions about split mirror setup for 3.4 etc. I have a �few more edits to do �before sending out a notification about final review (later today). But...I have a few questions for this release. * The DL scripts have a good amount of logic surrounding the naming/download of 3.2 and 3.1 releases-- the old naming schema. Since we won't be providing friendly DL buttons for these anymore, is it safe to pull this stuff out? * DL locations for Mac PPC and FreeBSD are as follows (excuse wrapping): var MIRROR_MAC_PPC_URL � � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/macosppc/;; var MIRROR_FREEBSD32_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86/;; var MIRROR_FREEBSD64_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86-64/;; Will this still be the case or will all versions be served from either Apache or SourceForge? The DL logic needs to be changed if this alternate URL is not used. I think the main download link should only provide links to official AOO releases. � We could have another section (maybe in other.html) where we can point to third party binaries and ports. �But we should have a disclaimer making it clear that these packages are not official releases. I also agree that we should not inter-mix 3.3 and 3.4 downloads. Another thing to consider is how we actually invoke the download. Right now we simply link to the SF site. �So after the download is done the user is left sitting at SF. �This is not ideal. � �I wonder whether it would be better to load the SF page in a new page, via target=_blank and then refresh our download.html to contribute.html so after the download is done, and the user closes the SF page, they are back in the openoffice website with a thanks for downloading messsage and followup info to engage the user in the community. Actually to avoid to open new pages we did modify the download page by adding all info previously available. We have been beta testing for over a week, and is now live. Hope this will remove the need to open new pages. Hi Roberto, So what we have today looks like this: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Win_x86_install-wJRE_en-US.exe/download After the download, on the left, are some boxes that contain all the info that we used to show to the user here: http://www.openoffice.org/download/contribute.html That is good, since it gives several different ways for the user to engage with the project, etc. However, it is less prominent than before and does require additional mouse clicks to navigate the different sections. � �I think it is less effective than what we had before. �For example, I'm seeing only 47 referrals since April 11th from SF to our Get Involved paged, the first link given. �We used to get hundreds of these from the old contribute.html page. I wonder if simpler would be better? �So instead of the pop-up page which I suggested before, and which is annoying for some users, maybe keep the SF as it is, but make the content simpler, with the aim of referring users back to contribute.html. So something like this: Thanks for downloading Apache OpenOffice, the free and open productivity suit. � We invite you to learn more about how to enhance your experience with OpenOffice, sign up to receive important notifications and learn how you can contribute to make the next version of OpenOffice even better. If we make it short and sweet like that, maybe even use some of the AOO graphical elements, then mayb we can improve the engagement? But I'm not a web UI/marketing expert. �Maybe someone has some other ideas. Working on it, it will be operative by next Monday. Roberto I love what SourceForge has done here by the way! Very nice! and very creative from the norm. Here we go, we put the suggested text with some links, plus the Participate icon. For example: http://sourceforge.net/projects/openofficeorg.mirror/files/localized/it/3.3.0/OOo_3.3.0_MacOS_x86_install_it.dmg/download Roberto super! SF is a wonderful partner. -Rob Roberto -Rob Thanks for your time. -- MzK Well, life has a funny way of sneaking up on you �And life has a funny way of helping you out �Helping you out. �
Re: [RELEASE} a few DL questions...
On Apr 30, 2012, at 2:56 PM, Rob Weir wrote: On Mon, Apr 30, 2012 at 5:48 PM, Roberto Galoppini rgalopp...@geek.net wrote: On Fri, Apr 27, 2012 at 11:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On 04/27/2012 01:57 PM, Roberto Galoppini wrote: On Thu, Apr 26, 2012 at 9:04 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 1:47 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Thu, Apr 26, 2012 at 7:02 PM, Rob Weirrobw...@apache.org wrote: On Thu, Apr 26, 2012 at 12:11 PM, Kay Schenkkay.sch...@gmail.com wrote: I've been working on a prototype of the DL button in the /download/test area given our discussions about split mirror setup for 3.4 etc. I have a �few more edits to do �before sending out a notification about final review (later today). But...I have a few questions for this release. * The DL scripts have a good amount of logic surrounding the naming/download of 3.2 and 3.1 releases-- the old naming schema. Since we won't be providing friendly DL buttons for these anymore, is it safe to pull this stuff out? * DL locations for Mac PPC and FreeBSD are as follows (excuse wrapping): var MIRROR_MAC_PPC_URL � � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/macosppc/;; var MIRROR_FREEBSD32_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86/;; var MIRROR_FREEBSD64_URL � �= http://ooopackages.good-day.net/pub/OpenOffice.org/contrib/freebsdx86-64/;; Will this still be the case or will all versions be served from either Apache or SourceForge? The DL logic needs to be changed if this alternate URL is not used. I think the main download link should only provide links to official AOO releases. � We could have another section (maybe in other.html) where we can point to third party binaries and ports. �But we should have a disclaimer making it clear that these packages are not official releases. I also agree that we should not inter-mix 3.3 and 3.4 downloads. Another thing to consider is how we actually invoke the download. Right now we simply link to the SF site. �So after the download is done the user is left sitting at SF. �This is not ideal. � �I wonder whether it would be better to load the SF page in a new page, via target=_blank and then refresh our download.html to contribute.html so after the download is done, and the user closes the SF page, they are back in the openoffice website with a thanks for downloading messsage and followup info to engage the user in the community. Actually to avoid to open new pages we did modify the download page by adding all info previously available. We have been beta testing for over a week, and is now live. Hope this will remove the need to open new pages. Hi Roberto, So what we have today looks like this: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Win_x86_install-wJRE_en-US.exe/download After the download, on the left, are some boxes that contain all the info that we used to show to the user here: http://www.openoffice.org/download/contribute.html That is good, since it gives several different ways for the user to engage with the project, etc. However, it is less prominent than before and does require additional mouse clicks to navigate the different sections. � �I think it is less effective than what we had before. �For example, I'm seeing only 47 referrals since April 11th from SF to our Get Involved paged, the first link given. �We used to get hundreds of these from the old contribute.html page. I wonder if simpler would be better? �So instead of the pop-up page which I suggested before, and which is annoying for some users, maybe keep the SF as it is, but make the content simpler, with the aim of referring users back to contribute.html. So something like this: Thanks for downloading Apache OpenOffice, the free and open productivity suit. � We invite you to learn more about how to enhance your experience with OpenOffice, sign up to receive important notifications and learn how you can contribute to make the next version of OpenOffice even better. If we make it short and sweet like that, maybe even use some of the AOO graphical elements, then mayb we can improve the engagement? But I'm not a web UI/marketing expert. �Maybe someone has some other ideas. Working on it, it will be operative by next Monday. Roberto I love what SourceForge has done here by the way! Very nice! and very creative from the norm. Here we go, we put the suggested text with some links, plus the Participate icon. For example: http://sourceforge.net/projects/openofficeorg.mirror/files/localized/it/3.3.0/OOo_3.3.0_MacOS_x86_install_it.dmg/download I like it. Thanks! +2. Thanks and Regards, Dave -Rob Roberto -Rob Roberto -Rob Thanks for your time. --
Re: Volunteers needed: To update NL download pages later this week
On Apr 30, 2012, at 2:43 PM, Rob Weir wrote: On Mon, Apr 30, 2012 at 3:58 PM, Reizinger Zoltán zreizin...@hdsnet.hu wrote: Hi Rob, 2012.04.30 21:41 időpontban Rob Weir ezt írta: The following tasks are on the wiki and need owners: Manually update the downloads from the Arabic NL homepage Manually update the downloads from the Czech NL homepage Manually update the downloads from the German NL homepage Manually update the downloads from the Spanish NL homepage Manually update the downloads from the French NL homepage Manually update the downloads from the Hungarian NL homepage I volunteer for Hungarian page, modified wiki Manually update the downloads from the Galacian NL homepage Manually update the downloads from the Italian NL homepage and subpages (pescetti) Manually update the downloads from the Japanese NL homepage Manually update the downloads from the Dutch NL homepage Manually update the downloads from the Brazilian NL homepage Manually update the downloads from the Russian NL homepage Manually update the downloads from the Simplified Chinese NL homepage Manually update the downloads from the Traditional Chinese NL homepage https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Only one of them has an owner (Thanks, Andrea!) What needs to be done? We need someone to review these NL pages and identify what needs to be changed to support the AOO 3..4 release. Changes to consider: 1) Branding changes (OpenOffice.org - Apache OpenOffice) 2) Updates to download location, for the 3.4 releases instead of the 3.3 release 3) References to the old LGPL license need to be changed to Apache 2.0 License 4) References to old NLC email addresses, marketing leads, etc., need to be replaced by the new Apache email lists. 5) Other similar changes. You don't need to do a complete rewrite of the pages. But we should refresh the page with information on the AOO 3.4 release. Timeline looks like this: -- Wednesday May 2nd -- Vote ends on approving the 3.4 release -- Thursday-Friday -- Update the mirrors with the release, test the new download websites. -- Over the weekend, additional website updates and testing -- Monday or Tuesday, if everything is working well, then we make public announcement So ideally we would have the NL website updates done at the end of this week. However, we should not make them be live on the production server until after the mirrors are populated. Maybe easiest way to coordinate is to submit patches for the changes into BZ? Any other ideas? My problem with the downloaded files from svn, which one needs to be changed? Good question. For Hungarian, the files are here; https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/hu/ My problem is that the old Hungarian OOo site contains files which was manually customized, the content and layout not match to the English site. How can I proceed, I download En site from svn and translate it, and upload to Hungarian part of svn? You could do that. Dave has some instructions for doing that: http://markmail.org/message/pnqr7qmdzrvricxq If you have time to translate and create a new Hungarian homepage that would be ideal. But if we can just patch the old page to update it for AOO 3.4, that is good for now. How can I check my work, I'm an only Hungarian in PPMC? It depends on how familiar you are with command line tools like Subversion. If you are, then just check out the files, modify and commit the changes. Otherwise you could make all your changes locally, zip them up and attach then to a BZ issue and I (or another developer) can check them in. I'll be around to help as well. Regards, Dave Thanks, -rob Zoltan Any volunteers? -Rob
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Am 04/30/2012 11:21 PM, schrieb Kay Schenk: On 04/30/2012 11:37 AM, Marcus (OOo) wrote: Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. I've tested the following: 1. Linux with Firefox -- Linux x86-64 RPM de -- the text in the pop-ups makes sense -- OK 2. Windows XP with MSIE -- error -- the detailed error message says: Line: 104 Char: 1 Error: Identifier, string or number
Re: Happy Birthday, OpenOffice!
Wow, really great find. :-) Thanks Marcus Am 05/01/2012 12:08 AM, schrieb Rob Weir: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! -Rob
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Hi, my test results are below, all on German WinXP Home, SP3. kind regards Regina Marcus (OOo) schrieb: Am 04/30/2012 11:21 PM, schrieb Kay Schenk: On 04/30/2012 11:37 AM, Marcus (OOo) wrote: Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/**download/test/index_new_dl.**htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/**security/cves/CVE-2012-0037.**htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/**incubator/ooo/http://www.apache.org/dist/incubator/ooo/ This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out. -- Ironic, Alanis Morissette Ok, I am hoping this will be about the last, final review on the new download/index.html -- prototype at: http://ooo-site.staging.apache.org/download/test/index_new_dl.html This assumes SourceForge ONLY, and that the 3.4 pre-built client packs will be in the hiearchy as the 3.3 is -- stable, etc. Naturally NONE of the links will work until something gets out there and there is a TON of alerts which I will of course eventually comment out. I've tested the following: 1. Linux with Firefox -- Linux x86-64 RPM de -- the text in the pop-ups makes sense -- OK 2. Windows XP with MSIE -- error -- the detailed error message says: Line: 104 Char:
Re: Happy Birthday, OpenOffice!
Wow, a real new start 发自我的 iPad 在 2012-5-1，上午6:49，Marcus (OOo) marcus.m...@wtnet.de 写道： Wow, really great find. :-) Thanks Marcus Am 05/01/2012 12:08 AM, schrieb Rob Weir: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! -Rob
Revised chapters for Getting Started with AOO need review
I revised the Preface to Getting Started with AOO. http://www.odfauthors.org/apache-openoffice/english/user-guides/getting-started-3.4/drafts/gs3.4-preface/view Among other changes, I added a section on What's new in v3.4. I took the info from the release notes on the wiki, https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+Notes Because I shortened that list to some bullet points, others may wish to check what I've done in case I misunderstood something, chose the wrong items, or made any other accidental errors. I also revised Chapter 12, which includes a section on the history of AOO/OOo; again, others may wish to check that I got it right. http://www.odfauthors.org/apache-openoffice/english/user-guides/getting-started-3.4/drafts/gs3.4-ch12-open../view It really would be nice to make any necessary corrections before publication. Thanks. I am also updating the other chapters to have the revised title page and other minor changes, but I've not got all of them done and uploaded yet. --Jean
Re: Draft blog post: Avoiding OpenOffice Download Scams
On 04/30/2012 11:10 AM, Rob Weir wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few questions a few comments: 1. I am confused regarding the use of trademarks: 'OpenOffice' and/or 'Apache OpenOffice'. A USTPO search shows only: Serial Number Reg. Number Word Mark Check Status Live/Dead 1 85298190OPENOFFICE TARRDEAD 2 790412343458383 HIPATH OPENOFFICE TARRLIVE 3 785812893063339 OPENOFFICE.ORG TARRLIVE 4 770214133287409 OPENOFFICE.ORG TARRLIVE 5 76087516OPENOFFICE.ORG TARRDEAD The 'OPENOFFICE' (85298190) mark was the one that Tightrope Interactive filed and later abandoned. Have Apache applied for 'OpenOffice' and 'Apache OpenOffice' as trademarks? Further: http://www.openoffice.org/about/ states: Because of trademark issues, OpenOffice.org must insist that all public communications refer to the project and software as OpenOffice.org or OpenOffice.org 3.x, and not OpenOffice or Open Office. Given that, should you not modify your blog from 'OpenOffice' to OpenOffice.org (or Apache Openoffice if indeed Apache have the trademark aproval)? 2. I'd recommend caution when generalizing statements about sites offering support and/or 3rd party installations with the downloads. While I detest a true scammer, I think it wise to look at sites like www.openoffice.us.com (Tightrope Interactive) whereby they provide full disclosure[1]. Further, it is quite likely that the 'user' did indeed download a 'genuine' copy of AO/OO.o - and only the 3rd party 'add-on'(s) were of issue. I suspect that this is what your 'user' ran into. Lack of proof that the 3rd party add-ons are actually spyware or malware could also lead to trouble. 3. I'd recommend against stating: o Remember this simple rule: www.openoffice.org is the official website for OpenOffice. That is the only official download site for OpenOffice.. That puts valid redistributors and applications providers like PortableApps (http://sourceforge.net/projects/portableoo/) in the 'scam' area. You may also run into 'user' issues when they go to www.openoffice.org, begin their download, and then see that the download is actually coming from a mirror/redirector site ala: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Linux_x86_install-rpm-wJRE_en-US.tar.gz/download Yes, you and I know how the mirror/redirectors work, but you've just told these 'users' that the only official website for downloading is www.openoffice.org. Remember, these are likely to be the same 'users' that neglected to read the T's C's when they downloaded AO/OOo from another website. o However, what no one has permission to do is modify OpenOffice and then confuse consumers into believing that it is actually still the OpenOffice product. . That is likely to put Apache on the defensive to prove that the 'consumer' didn't receive a proper copy of AO/OOo. IANAL so check with your legal folks regarding such statements. [1] Note: I'm not defending and/or advocating www.openoffice.us.com and am only using them as a sample. I think they have pretty much covered all of the disclosure bases: 1. Front web page: http://www.openoffice.us.com/ They state: OpenOffice is an open source product licensed under GNU LGPL v3. Source code for OpenOffice can be found here. and provide a link to openoffice.org. 2. Download Terms: http://www.openoffice.us.com/openoffice/download-terms.php Pretty well spell out what the terms are. 3. Terms of Service: http://www.openoffice.us.com/openoffice/terms-of-service.php 4. Privacy: http://www.openoffice.us.com/openoffice/privacy.php 5. Support: http://www.openoffice.us.com/openoffice/openoffice-support.php They provide links to OOo support. However they do not charge for this support state in their other pages that they make their money off of advertising (see 6 below) 6. Disclaimer: http://www.openoffice.us.com/openoffice/disclaimer.php Pretty clear IMO that Pricegong and Weatherbug are their advertisers. Does Apache really want to get into a legal cat fight with Earth Networks (WeatherBug is a brand of Earth Networks). Point being is that while you want to head off 'scammers', you also have to be careful
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Regina-- Thanks for all this work. Please see comments inline below... On Mon, Apr 30, 2012 at 4:13 PM, Regina Henschel rb.hensc...@t-online.dewrote: Hi, my test results are below, all on German WinXP Home, SP3. kind regards Regina Marcus (OOo) schrieb: Am 04/30/2012 11:21 PM, schrieb Kay Schenk: On 04/30/2012 11:37 AM, Marcus (OOo) wrote: Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/download/test/index_new_dl.htmlhttp://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.**org/download/test/index_new_**dl.htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/gmane.comp.apache.incubator.**http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://**comments.gmane.org/gmane.comp.** apache.incubator.ooo.devel/**16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/security/cves/CVE-2012-0037.htmlhttp://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.**org/security/cves/CVE-2012-**0037.htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/incubator/ooo/http://www.apache.org/dist/**incubator/ooo/ http://www.**apache.org/dist/incubator/ooo/http://www.apache.org/dist/incubator/ooo/ ** This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time is approaching and I can only hope that talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had started on this list, are progressing now. I think it is too late for any of those talks to influence how we deal with AOO 3.4 initial downloads. But maybe the update downloads in a couple of weeks. -Rob Regards, Andrea. -- --**--** MzK Well, life has a funny way of sneaking up on you
Re: Draft blog post: Avoiding OpenOffice Download Scams
On Mon, Apr 30, 2012 at 7:41 PM, NoOp gl...@sbcglobal.net wrote: On 04/30/2012 11:10 AM, Rob Weir wrote: https://blogs.apache.org/preview/OOo/?previewEntry=draft_avoiding_openoffice_download_scams I know Louis and others have dealt with these things for longer. Anything else I should mention? I considered adding a discussion of the importance of MD5 hashes, etc., but that is not really the skill level of the end user who downloads OpenOffice. I'm also cc'ing trademarks@ since it may be of interest to them and/or they might have feedback. A few questions a few comments: 1. I am confused regarding the use of trademarks: 'OpenOffice' and/or 'Apache OpenOffice'. A USTPO search shows only: Serial Number Reg. Number Word Mark Check Status Live/Dead 1 85298190 OPENOFFICE TARR DEAD 2 79041234 3458383 HIPATH OPENOFFICE TARR LIVE 3 78581289 3063339 OPENOFFICE.ORG TARR LIVE 4 77021413 3287409 OPENOFFICE.ORG TARR LIVE 5 76087516 OPENOFFICE.ORG TARR DEAD The 'OPENOFFICE' (85298190) mark was the one that Tightrope Interactive filed and later abandoned. Have Apache applied for 'OpenOffice' and 'Apache OpenOffice' as trademarks? Further: http://www.openoffice.org/about/ states: Because of trademark issues, OpenOffice.org must insist that all public communications refer to the project and software as OpenOffice.org or OpenOffice.org 3.x, and not OpenOffice or Open Office. Given that, should you not modify your blog from 'OpenOffice' to OpenOffice.org (or Apache Openoffice if indeed Apache have the trademark aproval)? I'm not sure how familiar you are with US trademark law, but there are registered trademarks, denoted with (R) or an R-in-circle, as well as unregistered trademarks, denoted by a TM. In the US unregistered trademarks offer quite a bit of protection. I agree that we should update the page that you linked to. 2. I'd recommend caution when generalizing statements about sites offering support and/or 3rd party installations with the downloads. While I detest a true scammer, I think it wise to look at sites like www.openoffice.us.com (Tightrope Interactive) whereby they provide full disclosure[1]. Further, it is quite likely that the 'user' did indeed download a 'genuine' copy of AO/OO.o - and only the 3rd party 'add-on'(s) were of issue. I suspect that this is what your 'user' ran into. Lack of proof that the 3rd party add-ons are actually spyware or malware could also lead to trouble. My blog post does not refer to any website or distributor. 3. I'd recommend against stating: o Remember this simple rule: www.openoffice.org is the official website for OpenOffice. That is the only official download site for OpenOffice.. That puts valid redistributors and applications providers like PortableApps (http://sourceforge.net/projects/portableoo/) in the 'scam' area. You may also run into 'user' issues when they go to www.openoffice.org, begin their download, and then see that the download is actually coming from a mirror/redirector site ala: http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.3.0/OOo_3.3.0_Linux_x86_install-rpm-wJRE_en-US.tar.gz/download There is only one official download site. There may be other sites that offer legitimate copies of OpenOffice as well, and are not scams. But that does not make them official download sites. But point taken about not confusing users when they face redirects to mirror sites, etc. I think I can clarify that. Yes, you and I know how the mirror/redirectors work, but you've just told these 'users' that the only official website for downloading is www.openoffice.org. Remember, these are likely to be the same 'users' that neglected to read the T's C's when they downloaded AO/OOo from another website. Right. So we can talk about links to downloads being on download.openoffice.org. o However, what no one has permission to do is modify OpenOffice and then confuse consumers into believing that it is actually still the OpenOffice product. . That is likely to put Apache on the defensive to prove that the 'consumer' didn't receive a proper copy of AO/OOo. IANAL so check with your legal folks regarding such statements. Absurd. [1] Note: I'm not defending and/or advocating www.openoffice.us.com and am only using them as a sample. I think they have pretty much covered all of the disclosure bases: Not necessarily. Putting a disclaimer does not mean you can do whatever you want. How far do you think you would get with a domain name called Microsoft.us.com, offering modified versions of products and using Microsoft logos, but then putting a small disclaimer on the page? 24 hours? 36 hours? 1. Front web page: http://www.openoffice.us.com/ They state: OpenOffice is an open source product licensed under GNU LGPL v3. Source code for OpenOffice
Re: Happy Birthday, OpenOffice!
On Mon, Apr 30, 2012 at 6:08 PM, Rob Weir robw...@apache.org wrote: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! Absolutely, we're just getting started. Thanks for bringing this to everyone's attention. -Rob
Re: Draft blog post: Avoiding OpenOffice Download Scams
On 04/30/2012 06:12 PM, Rob Weir wrote: On Mon, Apr 30, 2012 at 7:41 PM, NoOp ... wrote: ... o However, what no one has permission to do is modify OpenOffice and then confuse consumers into believing that it is actually still the OpenOffice product. . That is likely to put Apache on the defensive to prove that the 'consumer' didn't receive a proper copy of AO/OOo. IANAL so check with your legal folks regarding such statements. Absurd. And why would you feel that this is absurd? The entire blog is in reference to Avoiding OpenOffice Download Scams. In the second paragraph you state: the first thing I ask is, Where did you download OpenOffice from? In today's case, when the user checked his browser's history he found what I suspected, that it was not a genuine copy of OpenOffice, downloaded from www.openoffice.org, but a modified version that was installing applications that are variously known as adware, spyware or malware. My point is that I think you may be setting Apache up for having to prove that this claim is true. The user goes back to the website, claims that Apache informed him/her that this was not a genuine copy of OpenOffice(sic). User then goes to the BBB or media and claims the same. Website operator turns around and sues Apache; Apache are required to prove that it was not a genuine copy. Sorry, but many of these 'scammers' in the past have simply pointed their downloader to an OOo mirror - so the binary is an md5sum/bit-for-bit genuine copy. Even if someone (scammer or otherwise) were copy to their server supply the download from there, it very likely may actually be a bit-for-bit genuine copy. Here is a good example: http://download.cnet.com/OpenOffice-org/3000-18483_4-10263109.html Keep in mind (from your draft): Note that OpenOffice, with its open source software license, permits you and anyone else to redistribute it. You can make copies, give them away, sell them, put them on your website, etc. These are all permissions you have under the license. What is absurd is the FUD leading 'users' to believe that the only valid/genuine place a copy of OOo can be obtained is from www.openoffice.org. Certainly it is best practice to do so, but that is not the ony place they can obtain a genuine copy. Gary Lee [1] Note: I'm not defending and/or advocating www.openoffice.us.com and am only using them as a sample. I think they have pretty much covered all of the disclosure bases: Not necessarily. Putting a disclaimer does not mean you can do whatever you want. How far do you think you would get with a domain name called Microsoft.us.com, offering modified versions of products and using Microsoft logos, but then putting a small disclaimer on the page? 24 hours? 36 hours? 1. Front web page: http://www.openoffice.us.com/ They state: OpenOffice is an open source product licensed under GNU LGPL v3. Source code for OpenOffice can be found here. and provide a link to openoffice.org. 2. Download Terms: http://www.openoffice.us.com/openoffice/download-terms.php Pretty well spell out what the terms are. 3. Terms of Service: http://www.openoffice.us.com/openoffice/terms-of-service.php 4. Privacy: http://www.openoffice.us.com/openoffice/privacy.php 5. Support: http://www.openoffice.us.com/openoffice/openoffice-support.php They provide links to OOo support. However they do not charge for this support state in their other pages that they make their money off of advertising (see 6 below) 6. Disclaimer: http://www.openoffice.us.com/openoffice/disclaimer.php Pretty clear IMO that Pricegong and Weatherbug are their advertisers. Does Apache really want to get into a legal cat fight with Earth Networks (WeatherBug is a brand of Earth Networks). Point being is that while you want to head off 'scammers', you also have to be careful
Re: Volunteers needed: To update NL download pages later this week
Hi Rob, * On Mon, Apr 30, 2012 at 03:41:29PM -0400, Rob Weir wrote: The following tasks are on the wiki and need owners: Manually update the downloads from the Arabic NL homepage Manually update the downloads from the Czech NL homepage Manually update the downloads from the German NL homepage Manually update the downloads from the Spanish NL homepage I'll take this (and I'll try to find support in the Spanish mailing list). Manually update the downloads from the French NL homepage Manually update the downloads from the Hungarian NL homepage Manually update the downloads from the Galacian NL homepage Manually update the downloads from the Italian NL homepage and subpages (pescetti) Manually update the downloads from the Japanese NL homepage Manually update the downloads from the Dutch NL homepage Manually update the downloads from the Brazilian NL homepage Manually update the downloads from the Russian NL homepage Manually update the downloads from the Simplified Chinese NL homepage Manually update the downloads from the Traditional Chinese NL homepage https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Distribution+Tasks Only one of them has an owner (Thanks, Andrea!) What needs to be done? We need someone to review these NL pages and identify what needs to be changed to support the AOO 3..4 release. Changes to consider: 1) Branding changes (OpenOffice.org - Apache OpenOffice) 2) Updates to download location, for the 3.4 releases instead of the 3.3 release 3) References to the old LGPL license need to be changed to Apache 2.0 License 4) References to old NLC email addresses, marketing leads, etc., need to be replaced by the new Apache email lists. 5) Other similar changes. You don't need to do a complete rewrite of the pages. But we should refresh the page with information on the AOO 3.4 release. If you take a look at http://www.openoffice.org/es/ the page news almost a complete rewrite. * The main page look ugly * In some cases, the content does not seem to match the ASF way of doing things, lot of pages with dubious content, for example http://www.openoffice.org/es/comunidad/servicios.html http://www.openoffice.org/es/lecturas/lecturas_0022.html etc. * references to old mailing lists and list not under the ASF control http://www.openoffice.org/es/comunidad/listas.html * several dead links * etc. In short, the most practical solution here seems to simply translate the main pages from the English site. Timeline looks like this: -- Wednesday May 2nd -- Vote ends on approving the 3.4 release -- Thursday-Friday -- Update the mirrors with the release, test the new download websites. -- Over the weekend, additional website updates and testing -- Monday or Tuesday, if everything is working well, then we make public announcement So ideally we would have the NL website updates done at the end of this week. However, we should not make them be live on the production server until after the mirrors are populated. Maybe easiest way to coordinate is to submit patches for the changes into BZ? Given that time line, we better start translating from the English site. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpe3v2q6J5Wg.pgp Description: PGP signature
Re: Happy Birthday, OpenOffice!
Golly, a BIRTHDAY - I downloaded a free trial Illustrator and worked this up really quickly. It just didn't seem right not to attempt something for a 10 year old! I read that Apache celebrated their birthday in February (born 1995) https://cwiki.apache.org/confluence/download/attachments/27834483/OpenOfficeBookCover_A.svg Nancy Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Donald Harbison dpharbi...@gmail.com To: ooo-dev@incubator.apache.org Sent: Monday, April 30, 2012 6:19 PM Subject: Re: Happy Birthday, OpenOffice! On Mon, Apr 30, 2012 at 6:08 PM, Rob Weir robw...@apache.org wrote: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! Absolutely, we're just getting started. Thanks for bringing this to everyone's attention. -Rob
Ref cover sheet attempt and Happy Birthday, OpenOffice!
Golly, a BIRTHDAY - I downloaded a free trial Illustrator and worked this up really quickly. It just didn't seem right not to attempt something for a 10 year old! I read that Apache celebrated their birthday in February (born 1995) https://cwiki.apache.org/confluence/download/attachments/27834483/OpenOfficeBookCover_A.svg Nancy Nancy Web Design Free 24 hour pass to lynda.com. Video courses on SEO, CMS, Design and Software Courses From: Donald Harbison dpharbi...@gmail.com To: ooo-dev@incubator.apache.org Sent: Monday, April 30, 2012 6:19 PM Subject: Re: Happy Birthday, OpenOffice! On Mon, Apr 30, 2012 at 6:08 PM, Rob Weir robw...@apache.org wrote: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! Absolutely, we're just getting started. Thanks for bringing this to everyone's attention. -Rob
Re: [RELEASE] new DL test...needs review and comments, and probably correction
Kay- I've setup a new script for you to use for Openoffice downloads from Apache mirrors- simply replace closer.cgi with aoo-closer.cgi in your paths. Please don't forget this or users could be directed to mirrors which have opted out of carrying AOO releases. From: Kay Schenk kay.sch...@gmail.com To: ooo-dev@incubator.apache.org Sent: Monday, April 30, 2012 7:43 PM Subject: Re: [RELEASE] new DL test...needs review and comments, and probably correction Regina-- Thanks for all this work. Please see comments inline below... On Mon, Apr 30, 2012 at 4:13 PM, Regina Henschel rb.hensc...@t-online.dewrote: Hi, my test results are below, all on German WinXP Home, SP3. kind regards Regina Marcus (OOo) schrieb: Am 04/30/2012 11:21 PM, schrieb Kay Schenk: On 04/30/2012 11:37 AM, Marcus (OOo) wrote: Am 04/30/2012 04:53 AM, schrieb Kay Schenk: On Fri, Apr 27, 2012 at 3:22 PM, Kay Schenkkay.sch...@gmail.com wrote: On 04/27/2012 01:46 PM, Rob Weir wrote: On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescettipesce...@apache.org wrote: Kay Schenk wrote: Please take a look at and give feedback on a test page for the new /download/index.html page at: http://www.openoffice.org/download/test/index_new_dl.htmlhttp://www.openoffice.org/**download/test/index_new_dl.**html http://www.openoffice.**org/download/test/index_new_**dl.htmlhttp://www.openoffice.org/download/test/index_new_dl.html Yes, it's a bit strange with lots of nonsense at the top that I wanted you to see, but will of course go away in production. The page is nice, but it's the concept that leaves me dubious. We have another thread http://comments.gmane.org/gmane.comp.apache.incubator.**http://comments.gmane.org/**gmane.comp.apache.incubator.** ooo.devel/16219http://**comments.gmane.org/gmane.comp.** apache.incubator.ooo.devel/**16219http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 where there seems to be consensus towards a solution that: 1) Uses SF (and possibly Apache) for the web-based downloads 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., downloads initiated by OpenOffice with the Look for updates function) That's what I understand as well. oh -- OK. I thought we were going to use MirrorBrain for 3.3 DLs as well -- i.e. what Marcus will be working on. I know right now, we're using SourceForge for that though. The possibly Apache in 1) is due to the fact that I haven't understood yet what technology Apache will be using and if Apache will distribute only sources or binaries too (it's obvious that we as a project will release sources and binaries, but I'm not 100% sure that Apache wants to put binaries on its mirrors too: I think so). Well it's not all that complicated actually. Take a look at the security patch info page... http://www.openoffice.org/security/cves/CVE-2012-0037.htmlhttp://www.openoffice.org/**security/cves/CVE-2012-0037.**html http://www.openoffice.**org/security/cves/CVE-2012-**0037.htmlhttp://www.openoffice.org/security/cves/CVE-2012-0037.html and you can see what the link looks like. Actual source/binaries are, for us, put in: http://www.apache.org/dist/incubator/ooo/http://www.apache.org/dist/**incubator/ooo/ http://www.**apache.org/dist/incubator/ooo/http://www.apache.org/dist/incubator/ooo/ ** This said, you could be right in having issues tracking down problems. Right now, the SF setup is more user friendly in my opinion. I thought we were *required* to use Apache for downloads, but maybe we've gotten a dispensation for this release. Though I didn't think is was 100% someplace else. I admit I haven't kept up as much as I should have though. The other issue is how will it LOOK to users -- one moment they may be one place; if they happen to do a shift-reload, they may go someplace else with an entirely different look and feel. Fact is, we should avoid the random selection as much as possible, mainly to be able to quickly identify problems, and you will see details in that thread. The cleaner separation we can get, the better. So how about something very simple: 1) AOO 3.4 downloads use SourceForge by default from the /download/index.html page. Just like they are doing today. This WOULD make things a lot simpler. But we also have a links there that point to Apache mirrors for: a) Hashes and detached signatures b) source distribution c) a link to the full release tree Well, SF will need to implement in their sidebar or the main page for openoffice.org they have, right? Anyway, good conversation. In other words, no rolling the dice, noting fancy. 100% of normal users will download from SF. 2) When we enable the automated updates, in a week or two, then we decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. Maybe a mix, On the other side, release time
Re: Happy Birthday, OpenOffice!
Hey all, Folklore is an important part of any sustainable community, we should celebrate and promote this milestone. The anniversary could give our marketing push for 3.4 some great visibility. Finally, we can use the narrative as an opportunity for people to reflect on how they have used our product over the past years, and invite them to tell us how they would expect to use OpenOffice in the next ten years. UX could blog on this topic to start the conversation. I'll put it on my list. Some thoughts. Regards, Kevin On Tue, May 1, 2012 at 9:19 AM, Donald Harbison dpharbi...@gmail.comwrote: On Mon, Apr 30, 2012 at 6:08 PM, Rob Weir robw...@apache.org wrote: Anyone remember what happen 10 years ago today April 30th, 2002? http://www.openoffice.org/about_us/ooo_release.html And today the vote to approve the Apache OpenOffice 3.4 release ends. OpenOffice.org 1.0 took the community 18 months to produce. AOO 3.4 was a fast effort, in comparison. Here's to the next decade of OpenOffice! Absolutely, we're just getting started. Thanks for bringing this to everyone's attention. -Rob
