Re: [discussion] release mirror structure.
On 11/26/13 10:42 PM, jan i wrote: On 26 November 2013 22:06, Andrea Pescetti pesce...@apache.org wrote: On 25/11/2013 Jürgen Schmidt wrote: I at least understand the proposal but I don't support it because the multi language sets are not use friendly at the moment. We wouldn't link to it from the main download pages anyway. And of course the question is for what we do need the binaries on this mirrors if they are not found or used by the majority of our users. It's a secondary mirror system. Although due to the usual size/bandwidth considerations the OpenOffice project uses SourceForge, Infra did significant work to be able to offer OpenOffice on the Apache mirrors. We can do without it completely, but we can also make their life easier (last time they needed a full week to propagate OpenOffice to all mirrors) by storing there one multi-lang installer only. Do we have any numbers of downloads from these mirrors? No. We assume they are negligible, but we literally neglect them in our download statistics. That said, I honestly don't know how much the additional workload would be: is it only an additional option on the builbots (or build machines) configuration or will it be needed to adapt other scripts and waste a lot of time? I run it on my buildbots, the only difference is --with-lang=a b c , the difference in build time is not worth talking about this is not enough, you have probably specified your own pack.lst via configure. Including: OpenOffice_multilang platforms ast,cs,de,...zh-TW openoffice Juergen As jsc mentions it would be nice if the installer selected the language used on the OS, that would be a nice little programming exercise for a new developer. rgds jan I. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
On 25/11/2013 Jürgen Schmidt wrote: I at least understand the proposal but I don't support it because the multi language sets are not use friendly at the moment. We wouldn't link to it from the main download pages anyway. And of course the question is for what we do need the binaries on this mirrors if they are not found or used by the majority of our users. It's a secondary mirror system. Although due to the usual size/bandwidth considerations the OpenOffice project uses SourceForge, Infra did significant work to be able to offer OpenOffice on the Apache mirrors. We can do without it completely, but we can also make their life easier (last time they needed a full week to propagate OpenOffice to all mirrors) by storing there one multi-lang installer only. Do we have any numbers of downloads from these mirrors? No. We assume they are negligible, but we literally neglect them in our download statistics. That said, I honestly don't know how much the additional workload would be: is it only an additional option on the builbots (or build machines) configuration or will it be needed to adapt other scripts and waste a lot of time? Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
On 26 November 2013 22:06, Andrea Pescetti pesce...@apache.org wrote: On 25/11/2013 Jürgen Schmidt wrote: I at least understand the proposal but I don't support it because the multi language sets are not use friendly at the moment. We wouldn't link to it from the main download pages anyway. And of course the question is for what we do need the binaries on this mirrors if they are not found or used by the majority of our users. It's a secondary mirror system. Although due to the usual size/bandwidth considerations the OpenOffice project uses SourceForge, Infra did significant work to be able to offer OpenOffice on the Apache mirrors. We can do without it completely, but we can also make their life easier (last time they needed a full week to propagate OpenOffice to all mirrors) by storing there one multi-lang installer only. Do we have any numbers of downloads from these mirrors? No. We assume they are negligible, but we literally neglect them in our download statistics. That said, I honestly don't know how much the additional workload would be: is it only an additional option on the builbots (or build machines) configuration or will it be needed to adapt other scripts and waste a lot of time? I run it on my buildbots, the only difference is --with-lang=a b c , the difference in build time is not worth talking about As jsc mentions it would be nice if the installer selected the language used on the OS, that would be a nice little programming exercise for a new developer. rgds jan I. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
On 25 November 2013 01:43, Rob Weir robw...@apache.org wrote: On Sat, Nov 23, 2013 at 11:18 AM, Andrea Pescetti pesce...@apache.org wrote: Andrew Rist wrote: On 11/22/2013 1:52 AM, jan i wrote: Not having the binaries on apache.org is for sure the simplest solution, and if we can decide that, then I am sure infra wont have a problem. Actually, it was Infra who pushed for having the Apache mirrors as a secondary mirror network, after we followed their advice not to offer binaries from the Apache mirrors as a primary channel due to size/bandwidth constraints. I like the idea to have a secondary mirror network at Apache, while I find it too much if this delays our releases or requires us to change our processes. what if we have single install with all langs at apache.org? that way it is there, but considerably smaller from a real estate perspective but allows us to preserve binaries. For user downloads @ sourceforge, we continue to have the 1 per lang downloads that focus on the user. This sounds odd at first, but it could actually be a good solution. The multi-language build can be added to the SourceForge ones with minimal overhead, and it can be uploaded to the Apache mirrors very quickly. We would still have the possibility (this is an important one) to measure interest for the individual language builds by analyzing the SourceForge download data, while we would have the multi-language build available on both SF and Apache for archival and for those users who find this easier than download language packs. Any estimate for how large this would be? I assume it would include all the dictionaries as well, yes? the test shows 200-250Mb instead of 150Mb. rgds jan I. Another option could be to look at actual download numbers and package the most popular languages together, so maybe the top 15 languages or something like that. -Rob Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
On 25 November 2013 08:56, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/23/13 5:18 PM, Andrea Pescetti wrote: Andrew Rist wrote: On 11/22/2013 1:52 AM, jan i wrote: Not having the binaries on apache.org is for sure the simplest solution, and if we can decide that, then I am sure infra wont have a problem. Actually, it was Infra who pushed for having the Apache mirrors as a secondary mirror network, after we followed their advice not to offer binaries from the Apache mirrors as a primary channel due to size/bandwidth constraints. I like the idea to have a secondary mirror network at Apache, while I find it too much if this delays our releases or requires us to change our processes. what if we have single install with all langs at apache.org? that way it is there, but considerably smaller from a real estate perspective but allows us to preserve binaries. For user downloads @ sourceforge, we continue to have the 1 per lang downloads that focus on the user. This sounds odd at first, but it could actually be a good solution. The multi-language build can be added to the SourceForge ones with minimal overhead, and it can be uploaded to the Apache mirrors very quickly. We would still have the possibility (this is an important one) to measure interest for the individual language builds by analyzing the SourceForge download data, while we would have the multi-language build available on both SF and Apache for archival and for those users who find this easier than download language packs. To repeat myself such a mulit-language install set make only sense from my pov if the underlying code is able to select the UI language automatically and chose the correct one for the office UI. Minimal requirement would be an enhanced first start wizard that allow easy selection of the preferred language. Keep in mind we are producing an end user application and this kind of configuration should be done automatically for the user because many of our users would be confused. which is why we still have full language sets on SF, where our downloads happen. but I do think you put our users lower than they are, there are also many users who install a en-US package and then additional languages, simply because we live in an international world. rgds jan I. Juergen Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
On Sat, Nov 23, 2013 at 11:18 AM, Andrea Pescetti pesce...@apache.org wrote: Andrew Rist wrote: On 11/22/2013 1:52 AM, jan i wrote: Not having the binaries on apache.org is for sure the simplest solution, and if we can decide that, then I am sure infra wont have a problem. Actually, it was Infra who pushed for having the Apache mirrors as a secondary mirror network, after we followed their advice not to offer binaries from the Apache mirrors as a primary channel due to size/bandwidth constraints. I like the idea to have a secondary mirror network at Apache, while I find it too much if this delays our releases or requires us to change our processes. what if we have single install with all langs at apache.org? that way it is there, but considerably smaller from a real estate perspective but allows us to preserve binaries. For user downloads @ sourceforge, we continue to have the 1 per lang downloads that focus on the user. This sounds odd at first, but it could actually be a good solution. The multi-language build can be added to the SourceForge ones with minimal overhead, and it can be uploaded to the Apache mirrors very quickly. We would still have the possibility (this is an important one) to measure interest for the individual language builds by analyzing the SourceForge download data, while we would have the multi-language build available on both SF and Apache for archival and for those users who find this easier than download language packs. Any estimate for how large this would be? I assume it would include all the dictionaries as well, yes? Another option could be to look at actual download numbers and package the most popular languages together, so maybe the top 15 languages or something like that. -Rob Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] release mirror structure.
Am 11/22/2013 07:37 PM, schrieb Andrew Rist: On 11/22/2013 1:52 AM, jan i wrote: On 22 November 2013 10:34, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/22/13 9:52 AM, jan i wrote: Hi. We have been discussion to reduce our footprint on the mirrors, see: https://issues.apache.org/jira/browse/INFRA-6654 It would be wise of us to have this solved before we release 4.1, in order not to have a potential delay. anybody is free to work on this, as always at Apache the work have to be done The base discussion (please correct me if I am wrong) is which of 2 options we want. 1) as today, 1 full image for every language (approx. 150Mb each). This takes a lot of space on the mirrors, and lead to a little week for delay. 2) 1 full image containing all languages (--with-language). This takes the approx 200-250Mb). Advantage is fast copy to mirrors, users can online switch language. Disavantage. Users need to download a bit more. I have no strong opinions, except I dont like that we take up soo much space on the mirrors. we talk here mainly about some disk space on Apache mirrors. I can't remember who wanted the binaries on the Apache mirrors I personally can live with the binaries on the SF mirrors. For me most important is that we reduce the downloads for our millions of users. I am open for a working solution that make the download and installation for our users in the same way easy as what we have today. Disk space is for me not really a good argument. If we would have a multi-language install set only we would need a proper setup that select the correct language, so that users don't have to deal with an English version by default. The got potentially lost! Synchronizing the bits once on the mirrors seems to be peanuts compared to the millions of downloads. And to be honest I don't see that anybody will work on this in the near future, that is at least my impression. I don't like that we try to move an internal, technical problem to our million of users. Actually, I am one of millions who live abroad and use AOO with multiple languages, so at the moment, I compile my own version --with-lang=da es en-US so it can be used. But in general I agree with your point. Not having the binaries on apache.org is for sure the simplest solution, and if we can decide that, then I am sure infra wont have a problem. what if we have single install with all langs at apache.org? that way it is there, but considerably smaller from a real estate perspective but allows us to preserve binaries. For user downloads @ sourceforge, we continue to have the 1 per lang downloads that focus on the user. In this way we can point users with the special wish to have many or all languages in a single file to download. +1 for this nice compromise. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
