Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 02.06.2012 18:21, Kay Schenk wrote: On Fri, Jun 1, 2012 at 2:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.**openoffice.org/.http://update34.services.openoffice.org/. .. OOo 3.2.1 has the Update URL http://update35.services.**openoffice.org/.http://update35.services.openoffice.org/. .. But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). Oliver, don't go any further back than maybe 3.1. The 3.0 update URL is the one that uses POST instead of GET, and creates mayhem! This is update30 DO NOT redirect this one. I don't know about some of the others. We should probably be fie with update34, update 35. My personal opinion is that an update service for OOo 3.3, OOo 3.2.1 and OOo 3.2 is enough to reach our user base. May be also for OOo 3.1.1 and OOo 3.1, if we see a high number of users on OOo 3.2.1 and OOo 3.2. Everything else seems great! Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Mon, Jun 4, 2012 at 10:02 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 02.06.2012 18:21, Kay Schenk wrote: On Fri, Jun 1, 2012 at 2:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.**openoffice.org/.http://update34.services.openoffice.org/. .. OOo 3.2.1 has the Update URL http://update35.services.**openoffice.org/.http://update35.services.openoffice.org/. .. But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). Oliver, don't go any further back than maybe 3.1. The 3.0 update URL is the one that uses POST instead of GET, and creates mayhem! This is update30 DO NOT redirect this one. I don't know about some of the others. We should probably be fie with update34, update 35. My personal opinion is that an update service for OOo 3.3, OOo 3.2.1 and OOo 3.2 is enough to reach our user base. May be also for OOo 3.1.1 and OOo 3.1, if we see a high number of users on OOo 3.2.1 and OOo 3.2. Everything else seems great! Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? Roberto Best regards, Oliver. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 04.06.2012 10:11, Roberto Galoppini wrote: On Mon, Jun 4, 2012 at 10:02 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 02.06.2012 18:21, Kay Schenk wrote: On Fri, Jun 1, 2012 at 2:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.comwrote: [snip] One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.**openoffice.org/.http://update34.services.openoffice.org/. .. OOo 3.2.1 has the Update URL http://update35.services.**openoffice.org/.http://update35.services.openoffice.org/. .. But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). Oliver, don't go any further back than maybe 3.1. The 3.0 update URL is the one that uses POST instead of GET, and creates mayhem! This is update30 DO NOT redirect this one. I don't know about some of the others. We should probably be fie with update34, update 35. My personal opinion is that an update service for OOo 3.3, OOo 3.2.1 and OOo 3.2 is enough to reach our user base. May be also for OOo 3.1.1 and OOo 3.1, if we see a high number of users on OOo 3.2.1 and OOo 3.2. Everything else seems great! Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? If nobody objects and nothing unforeseen happened I would like to start tomorrow European morning at 10:00 (GMT+2). FYI, I have to check with ASF infrastructure team, if the redirect will be available at this time. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 04.06.2012 11:29, Oliver-Rainer Wittmann wrote: Hi, On 04.06.2012 10:11, Roberto Galoppini wrote: On Mon, Jun 4, 2012 at 10:02 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 02.06.2012 18:21, Kay Schenk wrote: On Fri, Jun 1, 2012 at 2:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.**openoffice.org/.http://update34.services.openoffice.org/. .. OOo 3.2.1 has the Update URL http://update35.services.**openoffice.org/.http://update35.services.openoffice.org/. .. But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). Oliver, don't go any further back than maybe 3.1. The 3.0 update URL is the one that uses POST instead of GET, and creates mayhem! This is update30 DO NOT redirect this one. I don't know about some of the others. We should probably be fie with update34, update 35. My personal opinion is that an update service for OOo 3.3, OOo 3.2.1 and OOo 3.2 is enough to reach our user base. May be also for OOo 3.1.1 and OOo 3.1, if we see a high number of users on OOo 3.2.1 and OOo 3.2. Everything else seems great! Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? If nobody objects and nothing unforeseen happened I would like to start tomorrow European morning at 10:00 (GMT+2). FYI, I have to check with ASF infrastructure team, if the redirect will be available at this time. ASF infrastructure team has established the redirect. It needs to be propagated through the dns servers - will take some time. I will check the redirect today. May be I will also get some numbers in advance - how many OOo 3.3 instances are trying today to contact the update service. Our first phase XML document check.Update will be in place tomorrow morning. I have a working copy a the same URL as file check.Update.full. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 04.06.2012 12:11, Oliver-Rainer Wittmann wrote: On 04.06.2012 10:11, Roberto Galoppini wrote: [snip] Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? If nobody objects and nothing unforeseen happened I would like to start tomorrow European morning at 10:00 (GMT+2). FYI, I have to check with ASF infrastructure team, if the redirect will be available at this time. ASF infrastructure team has established the redirect. It needs to be propagated through the dns servers - will take some time. I will check the redirect today. May be I will also get some numbers in advance - how many OOo 3.3 instances are trying today to contact the update service. I have checked the redirect - it is working. Thanks a lot to the ASF infrastructure team which helped me a lot. Since the redirect has been established at approx. noon in Europe we already had more than 600k HTTP GET request to the (currently not existing) check.Update file. Thus, I am looking forward to what will happen tomorrow. Best regards, Oliver. Our first phase XML document check.Update will be in place tomorrow morning. I have a working copy a the same URL as file check.Update.firstphase. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Mon, Jun 4, 2012 at 11:39 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 04.06.2012 12:11, Oliver-Rainer Wittmann wrote: On 04.06.2012 10:11, Roberto Galoppini wrote: [snip] Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? If nobody objects and nothing unforeseen happened I would like to start tomorrow European morning at 10:00 (GMT+2). FYI, I have to check with ASF infrastructure team, if the redirect will be available at this time. ASF infrastructure team has established the redirect. It needs to be propagated through the dns servers - will take some time. I will check the redirect today. May be I will also get some numbers in advance - how many OOo 3.3 instances are trying today to contact the update service. I have checked the redirect - it is working. Thanks a lot to the ASF infrastructure team which helped me a lot. Since the redirect has been established at approx. noon in Europe we already had more than 600k HTTP GET request to the (currently not existing) check.Update file. Does one HTTP request == 1 update check? Or if the server is down, are there multiple retries? Thus, I am looking forward to what will happen tomorrow. Best regards, Oliver. Our first phase XML document check.Update will be in place tomorrow morning. I have a working copy a the same URL as file check.Update.firstphase. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, Am 04.06.12 19:22, schrieb Rob Weir: On Mon, Jun 4, 2012 at 11:39 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] Thanks. Let see what happens, when we start tomorrow with the Italian OOo 3.3 update service. Tomorrow at which time? If nobody objects and nothing unforeseen happened I would like to start tomorrow European morning at 10:00 (GMT+2). FYI, I have to check with ASF infrastructure team, if the redirect will be available at this time. ASF infrastructure team has established the redirect. It needs to be propagated through the dns servers - will take some time. I will check the redirect today. May be I will also get some numbers in advance - how many OOo 3.3 instances are trying today to contact the update service. I have checked the redirect - it is working. Thanks a lot to the ASF infrastructure team which helped me a lot. Since the redirect has been established at approx. noon in Europe we already had more than 600k HTTP GET request to the (currently not existing) check.Update file. Does one HTTP request == 1 update check? Or if the server is down, are there multiple retries? These were 600k HTTP GET requests from unique IP adresses. The overall number was more than 1M HTTP GET requests. There was not made a deeper analysis, if all HTTP GET requests are coming from OOo 3.3 instances. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 02/06/2012 Roberto Galoppini wrote: Andrea, that page looks actually like the localized version of http://www.openoffice.org/download/ right? Both seems a very good start, I think. http://www.openoffice.org/it/download/ is now aligned with the international and the Spanish page. It is slightly customized, including some minor validity fixes. What about putting the Please Contribute content we have on SourceForge download pages? Thanks, I included links from that block in the right hand side column, while preserving the links we used to have there. Regards, Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Sat, Jun 2, 2012 at 12:51 AM, Andrea Pescetti pesce...@apache.org wrote: On 01/06/2012 Oliver-Rainer Wittmann wrote: On 01.06.2012 15:09, Rob Weir wrote: Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). Ok, I will update it. Both http://www.openoffice.org/it/ and the current one http://www.openoffice.org/it/download would do; the latter is much uglier since CSS were not imported correctly with the relocation to Apache. For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade I will check for the Italian download page for our first phase next week. We can see if we manage to refresh http://www.openoffice.org/it/download in a way similar to the Spanish page in the meantime (no problem if it is not yet available as a template localizable via mdtext; we can likely just grab the HTML from the Spanish site for the time being). Andrea, that page looks actually like the localized version of http://www.openoffice.org/download/ right? Both seems a very good start, I think. Thanks Roberto for offering to help with the landing pages; maybe we can discuss what to write/put in the right hand column, see the Spanish example at http://www.openoffice.org/es/descargar/index.html and the existing links at http://www.openoffice.org/it/download/3.4.0/download340.html What about putting the Please Contribute content we have on SourceForge download pages? Roberto Regards, Andrea. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Fri, Jun 1, 2012 at 2:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 31.05.2012 19:56, Rob Weir wrote: On Thu, May 31, 2012 at 4:38 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. Is the text in the dialog box in OOo 3.3 localized? The text that says an update is available, please go to this page to download? Or is that in English only? It is localized. One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. (En is the exception -- we'd send them to http://download.openoffice.org directly) +1 for using the NL pages as the update landing pages. To distinguish these visits from non-upgrade visits, we could tag them using URL parameters in a way that Google Analytics can understand. For example: http://www.openoffice.org/**download.html?utm_source=OOo3_** 3utm_medium=Clientutm_**campaign=Upgradehttp://www.openoffice.org/download.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or http://www.openoffice.org/de/**index.html?utm_source=OOo3_3** utm_medium=Clientutm_**campaign=Upgradehttp://www.openoffice.org/de/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or http://www.openoffice.org/it/**index.html?utm_source=OOo3_3** utm_medium=Clientutm_**campaign=Upgradehttp://www.openoffice.org/it/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade The extra parameters would be ignored by our website, but GA would understand them. No problem to include such parameters. One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.**openoffice.org/.http://update34.services.openoffice.org/. .. OOo 3.2.1 has the Update URL http://update35.services.**openoffice.org/.http://update35.services.openoffice.org/. .. But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). Oliver, don't go any further back than maybe 3.1. The 3.0 update URL is the one that uses POST instead of GET, and creates mayhem! This is update30 DO NOT redirect this one. I don't know about some of the others. We should probably be fie with update34, update 35. Everything else seems great! We can redirect these URLs to another XML document which contains different update landing page URLs in order to distinguish e.g. OOo 3.2 update requests from OOo 3.3 update requests. Before activating the update service for former versions I would like to think about including languages/platform combinations for which we do _not_ have yet an installation package available. It could be a possibility to aware these users about the AOO 3.4 release. May be we can get feedback which languages and/or platforms our users are requesting. May be we can activate certain volunteers for these languages/platforms. May be certain users would be also satisfied with another localization. Do we think there are many out there? I do not know. OOo 3.2 was released at 2010-02-11, OOo 3.2.1 at 2010-06-03. OOo 3.3 was out at 2011-01-27. I assume that at this time the former update services for OOo 3.2 and OOo 3.2.1 were available. Thus, the users had at least 2,5
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 31.05.2012 23:59, Andrea Pescetti wrote: Oliver-Rainer Wittmann wrote: (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) You actually mean June, right? I mean, tests will start as soon as next week. Or do you actually mean July? I see no reasons for such a long wait. Yes, I mean June - sorry for the typo. Please read my proposal: 2012-06-05 until 2012-06-08 Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 31.05.2012 18:46, Roberto Galoppini wrote: On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. Clear. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms agree (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. I can volunteer for this, do we have a draft text for that? No, there is no draft. But Rob suggested in his reply to provide links to the corresponding NL pages. Andrea second it and I am also in favor of it. It would save us some resources. The needed updates to the NL pages have to be done nevertheless in my opinion. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) SourceForge's side we are ok with this tentative schedule. I meant 2012-06-05 until 2012-06-08, as it has been already recognized. Best regards, Oliver. BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Fri, Jun 1, 2012 at 10:55 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 31.05.2012 18:46, Roberto Galoppini wrote: On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. Clear. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms agree (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. I can volunteer for this, do we have a draft text for that? No, there is no draft. But Rob suggested in his reply to provide links to the corresponding NL pages. Andrea second it and I am also in favor of it. It would save us some resources. agree The needed updates to the NL pages have to be done nevertheless in my opinion. Andrea are you going to do that or do you want me to do so? Roberto (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) SourceForge's side we are ok with this tentative schedule. I meant 2012-06-05 until 2012-06-08, as it has been already recognized. Best regards, Oliver. BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 31.05.2012 19:56, Rob Weir wrote: On Thu, May 31, 2012 at 4:38 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. Is the text in the dialog box in OOo 3.3 localized? The text that says an update is available, please go to this page to download? Or is that in English only? It is localized. One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. (En is the exception -- we'd send them to http://download.openoffice.org directly) +1 for using the NL pages as the update landing pages. To distinguish these visits from non-upgrade visits, we could tag them using URL parameters in a way that Google Analytics can understand. For example: http://www.openoffice.org/download.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or http://www.openoffice.org/de/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or http://www.openoffice.org/it/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade The extra parameters would be ignored by our website, but GA would understand them. No problem to include such parameters. One other question: does this take care of OOo 3.2 upgrades as well? Not yet planned nor tested, but I assume that the XML document only needs minor adjustments. OOo 3.2 has the UpdateURL http://update34.services.openoffice.org/... OOo 3.2.1 has the Update URL http://update35.services.openoffice.org/... But once the update service is working for OOo 3.3, we can easily do the same for OOo 3.2 and OOo 3.2.1 (and even former versions). We can redirect these URLs to another XML document which contains different update landing page URLs in order to distinguish e.g. OOo 3.2 update requests from OOo 3.3 update requests. Before activating the update service for former versions I would like to think about including languages/platform combinations for which we do _not_ have yet an installation package available. It could be a possibility to aware these users about the AOO 3.4 release. May be we can get feedback which languages and/or platforms our users are requesting. May be we can activate certain volunteers for these languages/platforms. May be certain users would be also satisfied with another localization. Do we think there are many out there? I do not know. OOo 3.2 was released at 2010-02-11, OOo 3.2.1 at 2010-06-03. OOo 3.3 was out at 2011-01-27. I assume that at this time the former update services for OOo 3.2 and OOo 3.2.1 were available. Thus, the users had at least 2,5 months (until mid April 2011) to upgrade. May be former update services were longer available - I do not know. I could conclude that our OOo 3.2/3.2.1 user base is small compared to the OOo 3.3 one from these assumption, but I am not sure. Best regards, Oliver. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 01.06.2012 11:05, Roberto Galoppini wrote: On Fri, Jun 1, 2012 at 10:55 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 31.05.2012 18:46, Roberto Galoppini wrote: On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. Clear. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms agree (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. I can volunteer for this, do we have a draft text for that? No, there is no draft. But Rob suggested in his reply to provide links to the corresponding NL pages. Andrea second it and I am also in favor of it. It would save us some resources. agree The needed updates to the NL pages have to be done nevertheless in my opinion. Andrea are you going to do that or do you want me to do so? Rob already made a corresponding investigation and started a thread here [1]. As far as I can see from this thread the italian NL pages is in a good shape. [1] http://ooo-dev.markmail.org/thread/7ydafrdrqxpctsy3 Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, next and refined steps - see below. Please hold me back, if the schedule is too tough. Best regards, Oliver. On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms It looks like we will go for it. Thus, I will reduce the current XML document to the italian entries. (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) Needs to be read: 2012-06-05 until 2012-06-08 As the italian NL page is in a good shape and no objections are raised so far I think we can go for it. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, some status update - see below On 01.06.2012 11:58, Oliver-Rainer Wittmann wrote: Hi, next and refined steps - see below. Please hold me back, if the schedule is too tough. Best regards, Oliver. On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms It looks like we will go for it. Thus, I will reduce the current XML document to the italian entries. I have updated the current XML document [1] The full version can be found at [2] or [3]. (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. The XML document (and the full version) now contain links to the NL pages inclusive the Google Analytics tracking parameter. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) Needs to be read: 2012-06-05 until 2012-06-08 As the italian NL page is in a good shape and no objections are raised so far I think we can go for it. [1] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [2] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update.full [3] http://people.apache.org/~orw/testupdateservice/check.Update Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 01.06.2012 14:29, Oliver-Rainer Wittmann wrote: [snip] (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. I have submitted JIRA issue INFRA-4871, found at https://issues.apache.org/jira/browse/INFRA-4871 I am currently trying to get in direct contact with the ASF infrastructure team to discuss details and to clarify, if the request (INFRA-4871) can be fulfilled. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, next and refined steps - see below. Please hold me back, if the schedule is too tough. Best regards, Oliver. On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms It looks like we will go for it. Thus, I will reduce the current XML document to the italian entries. (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. That is correct for upgrades from the 3.3 client. But we would change the utm_source parameter when we enable OOo 3.2. updates. Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) Needs to be read: 2012-06-05 until 2012-06-08 As the italian NL page is in a good shape and no objections are raised so far I think we can go for it. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 01.06.2012 15:09, Rob Weir wrote: On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, next and refined steps - see below. Please hold me back, if the schedule is too tough. Best regards, Oliver. On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms It looks like we will go for it. Thus, I will reduce the current XML document to the italian entries. (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. That is correct for upgrades from the 3.3 client. But we would change the utm_source parameter when we enable OOo 3.2. updates. Ok and yes, the parameter can be changed for the update service of other versions. Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). Ok, I will update it. Recently, I have removed the already reduced XML document, because the ASF infrastructure wants to establish the redirect before 2012-06-05. Thus, our first phase will start, when I (or somebody else) recreate it. For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade I will check for the Italian download page for our first phase next week. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Fri, Jun 1, 2012 at 3:42 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 01.06.2012 15:09, Rob Weir wrote: On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, next and refined steps - see below. Please hold me back, if the schedule is too tough. Best regards, Oliver. On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote: [snip] Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms It looks like we will go for it. Thus, I will reduce the current XML document to the italian entries. (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task I will try to get in contact with ASF infrastructure team today. (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. That is correct for upgrades from the 3.3 client. But we would change the utm_source parameter when we enable OOo 3.2. updates. Ok and yes, the parameter can be changed for the update service of other versions. Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). Ok, I will update it. Recently, I have removed the already reduced XML document, because the ASF infrastructure wants to establish the redirect before 2012-06-05. Thus, our first phase will start, when I (or somebody else) recreate it. For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade I will check for the Italian download page for our first phase next week. Cool, so it seems we are in good shape to start this early next week. Let me know when we need start monitoring the auto-update traffic for the Italian releases. Thanks, Roberto Best regards, Oliver. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 01.06.2012 15:09, Rob Weir wrote: On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. Instead of a new landing page it looks like that we will go for the corresponding NL pages. I will update the links in the XML document accordingly. Rob: Can you provide the URL parameters for the Google Analytics tracking? I will use ?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade when I am updating the XML document. Please refine, if needed - Thx in advance. That is correct for upgrades from the 3.3 client. But we would change the utm_source parameter when we enable OOo 3.2. updates. Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade I have check some of the NL pages. Some are linking to localized download sites, some to the English one. For our first phase we only need the Italian one. This is already available [1]. I will fill the XML document check.Update.full with the localized download pages. The languages which have no localized ones I will keep the NL home page. We have then time until next Thursday to update these pages and the corresponding links. [1] http://www.openoffice.org/it/download/ Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 01/06/2012 Oliver-Rainer Wittmann wrote: On 01.06.2012 15:09, Rob Weir wrote: Also, if we follow Andrea's proposal, we don't link to the NL home page, but to the NL's download page directly. (If I understand correctly). Ok, I will update it. Both http://www.openoffice.org/it/ and the current one http://www.openoffice.org/it/download would do; the latter is much uglier since CSS were not imported correctly with the relocation to Apache. For example, Spanish upgrade URL would be: http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade I will check for the Italian download page for our first phase next week. We can see if we manage to refresh http://www.openoffice.org/it/download in a way similar to the Spanish page in the meantime (no problem if it is not yet available as a template localizable via mdtext; we can likely just grab the HTML from the Spanish site for the time being). Thanks Roberto for offering to help with the landing pages; maybe we can discuss what to write/put in the right hand column, see the Spanish example at http://www.openoffice.org/es/descargar/index.html and the existing links at http://www.openoffice.org/it/download/3.4.0/download340.html Regards, Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 30.05.2012 12:43, Oliver-Rainer Wittmann wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Andre and myself have tested the following use cases: - Ubuntu Linux, 64bit, language nl - Windows 7, language it - Windows 7, language en-us - MacOS X, language nl - MacOS X, language bn All worked as expected. Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 30.05.2012 22:09, Rob Weir wrote: On Wed, May 30, 2012 at 3:31 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. So, if we know from existing AOO 3.4 downloads that language/platform X is Y% of the total, then if we test the OOo 3.3 upgrade with only X, we can project what the total upgrade volume would be. That sounds reasonable. Ideally we'd like to start the test phase as soon as possible. Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 30.05.2012 22:09, Rob Weir wrote: On Wed, May 30, 2012 at 3:31 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. So, if we know from existing AOO 3.4 downloads that language/platform X is Y% of the total, then if we test the OOo 3.3 upgrade with only X, we can project what the total upgrade volume would be. That sounds reasonable. Ideally we'd like to start the test phase as soon as possible. Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. Clear. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms agree (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. I can volunteer for this, do we have a draft text for that? (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) SourceForge's side we are ok with this tentative schedule. Roberto BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html Best regards, Oliver. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Thu, May 31, 2012 at 4:38 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 30.05.2012 22:09, Rob Weir wrote: On Wed, May 30, 2012 at 3:31 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. So, if we know from existing AOO 3.4 downloads that language/platform X is Y% of the total, then if we test the OOo 3.3 upgrade with only X, we can project what the total upgrade volume would be. That sounds reasonable. Ideally we'd like to start the test phase as soon as possible. Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. Is the text in the dialog box in OOo 3.3 localized? The text that says an update is available, please go to this page to download? Or is that in English only? One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. (En is the exception -- we'd send them to http://download.openoffice.org directly) To distinguish these visits from non-upgrade visits, we could tag them using URL parameters in a way that Google Analytics can understand. For example: http://www.openoffice.org/download.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Am 05/31/2012 07:56 PM, schrieb Rob Weir: On Thu, May 31, 2012 at 4:38 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 30.05.2012 22:09, Rob Weir wrote: On Wed, May 30, 2012 at 3:31 PM, Roberto Galoppinirgalopp...@geek.net wrote: On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.comwrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. So, if we know from existing AOO 3.4 downloads that language/platform X is Y% of the total, then if we test the OOo 3.3 upgrade with only X, we can project what the total upgrade volume would be. That sounds reasonable. Ideally we'd like to start the test phase as soon as possible. Ok. Roberto, Rob and Kay are in favor to activate the update service only for a part of the possible OOo 3.3 instances in order to check, if the traffic can be handled. No objections from my side. One important remark which I had not given yet: When we had the redirect from [5] to [4] established by the ASF infrastructure team, all (yes, all) installed OOo 3.3 instances in which the check of updates is initiated will get the XML document. Whose which find an entry with their data (language, platform, architecture) will state that an update is available. All the others will state that the OOo 3.3 installation is up to date. To start this first phase the following tasks need to be finished: (1) Choose the OOo 3.3 candidates for the first phase. -- orw's proposal: italian on all four platforms (2) Get in contact with the ASF infrastructure team to get the redirect established at a certain day. -- orw is volunteering for this task (3) Fill the landing page [6] with content and links and activate tracking for this page. -- at least one volunteer is needed here. (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) BTW, as we have for each language own entries in the XML document we can provide translated landing pages if somebody is willing to translate the master landing page. Is the text in the dialog box in OOo 3.3 localized? The text that says an update is available, please go to this page to download? Or is that in English only? A second ago I've tried it also with German and I get a German text in the dialog box. Marcus One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. (En is the exception -- we'd send them to http://download.openoffice.org directly) To distinguish these visits from non-upgrade visits, we could tag them using URL parameters in a way that Google Analytics can understand. For example: http://www.openoffice.org/download.html?utm_source=OOo3_3utm_medium=Clientutm_campaign=Upgrade or
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Rob Weir wrote: One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. Sure, this makes a lot of sense. Testing with the Italian version is reasonable because it's approximately 10% of traffic, so a perfect sample; the only issue I see is that 80%-90% of the downloads of the Italian version come from Italy, so this wouldn't be a test for the global mirror network. One other question: does this take care of OOo 3.2 upgrades as well? No, every version uses a separate hostname: update36.services.openoffice.org will only be accessed by version 3.3. Do we think there are many out there? Enough to crash the openoffice.org web server: if I recall correctly, we had big troubles when all updateXY hostnames were redirected to openoffice.org (and the reason was determined to be very old, maybe even 2.x, versions, sending POST requests in an uncontrolled way). But as Oliver wrote we can progressively extend to 3.2 and possibly to earlier releases too. Regards, Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Thu, May 31, 2012 at 10:36 PM, Andrea Pescetti pesce...@apache.org wrote: Rob Weir wrote: One approach might be to have the landing page be the NL home page, e.g., http://de.openoffice.org. These already exist, and either have the download links on that page, or have text that explains how to download. Sure, this makes a lot of sense. Testing with the Italian version is reasonable because it's approximately 10% of traffic, so a perfect sample; the only issue I see is that 80%-90% of the downloads of the Italian version come from Italy, so this wouldn't be a test for the global mirror network. It's not a stress-test, but a practical way to guess how many auto-updates we'll be serving. One other question: does this take care of OOo 3.2 upgrades as well? No, every version uses a separate hostname: update36.services.openoffice.org will only be accessed by version 3.3. Do we think there are many out there? Enough to crash the openoffice.org web server: if I recall correctly, we had big troubles when all updateXY hostnames were redirected to openoffice.org (and the reason was determined to be very old, maybe even 2.x, versions, sending POST requests in an uncontrolled way). But as Oliver wrote we can progressively extend to 3.2 and possibly to earlier releases too. The fact that the web server crashed doesn't say much, though. The test phase will put us in the position to make educated guess about the expected global traffic, and we'll get prepared to serve them all. I like the idea of moving progressively to 3.2 and beyond. Roberto Regards, Andrea. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Oliver-Rainer Wittmann wrote: (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) You actually mean June, right? I mean, tests will start as soon as next week. Or do you actually mean July? I see no reasons for such a long wait. Regards, Andrea.
[offlist] Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Thanks - I was about to point this out, too I think it is more typo than plan... ;-) A. On 5/31/2012 2:59 PM, Andrea Pescetti wrote: Oliver-Rainer Wittmann wrote: (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) You actually mean June, right? I mean, tests will start as soon as next week. Or do you actually mean July? I see no reasons for such a long wait. Regards, Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
or onlist On 5/31/2012 3:09 PM, Andrew Rist wrote: Thanks - I was about to point this out, too I think it is more typo than plan... ;-) A. On 5/31/2012 2:59 PM, Andrea Pescetti wrote: Oliver-Rainer Wittmann wrote: (4) Choose the time frame for the first phase. -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established on Tuesday, 2012-07-05 and task (3) can be finished until Monday.) You actually mean June, right? I mean, tests will start as soon as next week. Or do you actually mean July? I see no reasons for such a long wait. Regards, Andrea. -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847
[HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. Ideally we'd like to start the test phase as soon as possible. Roberto The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Best regards, Oliver. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Wed, May 30, 2012 at 3:31 PM, Roberto Galoppini rgalopp...@geek.net wrote: On Wed, May 30, 2012 at 12:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. Hi Oliver, could we eventually jointly work on a test phase for a fraction of the user base? Maybe we could enable the auto-updates for a given language, or so. Actually this could help us to make some realistic assumptions on the total load, and if needed the necessary adjustments to ensure the optimal performance. So, if we know from existing AOO 3.4 downloads that language/platform X is Y% of the total, then if we test the OOo 3.3 upgrade with only X, we can project what the total upgrade volume would be. That sounds reasonable. Ideally we'd like to start the test phase as soon as possible. Roberto The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Best regards, Oliver. -- 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: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Am 05/30/2012 12:43 PM, schrieb Oliver-Rainer Wittmann: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Best regards, Oliver. I've tested on Linux with OOo 3.3.0 (OOO330m20 Build 9567). A restart was not necessary but doing so has shown exactly the same result. Via Help - Check for updates and after 2 seconds I got the following text in the dialog box: OpenOffice.org - Apache OpenOffice 3.4 is available. The installed version is OpenOffice.org 3.3.0. Note: Before dwnloading an update ... When clicking on the [Download] button I get to this webpage with the dummy text: http://www.openoffice.org/projects/update36/ProductUpdateService/ So, for me it seems to work well. :-) Marcus
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Wed, May 30, 2012 at 6:43 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/testupdateservice/ [4] http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. I'm testing on Windows XP SP3, a clean install of OOo 3.3.0 en_US. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. OK. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). It was in c:\Program files\OpenOffice.org 3\program (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~orw/testupdateservice/check.Update;. I replaced with: http://update36.services.openoffice.org/ProductUpdateService/check.Update Please keep an existing query part, e.g. ?pkgformat=rpm. My original string did not have any URL parameters like that. (step 4) start your OOo 3.3 OK (step 5a) check for an update manually via Menu Help - Check for Updates OK. (step 5b) wait for the automatic update check configured via Menu Tools - I did not need to wait long. It returned immediately with the note that Apache OpenOffice 3.4 is available Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Clicking download loads the correct webpage into the browser. Good work, Oliver! So, for the landing page, we'll want to remind users that they need to exit OOo 3.3 before installing AOO 3.4 -Rob Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/download Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Wed, May 30, 2012 at 3:43 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 22.05.2012 15:21, Oliver-Rainer Wittmann wrote: [snip] It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next week. Any objections? Any volunteers in advance which want to test? If yes, please provide information about your OOo 3.3 installation (operating system and language) and the test cases (direct download link, link to download page, ...) you want to test. [3] http://people.apache.org/~orw/**testupdateservice/http://people.apache.org/%7Eorw/testupdateservice/ [4] http://www.openoffice.org/**projects/update36/** ProductUpdateService/check.**Updatehttp://www.openoffice.org/projects/update36/ProductUpdateService/check.Update [5] http://update36.services.**openoffice.org/** ProductUpdateService/check.**Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update I have finished the creation of an XML document. It contains a feed with entries for all platform and language combinations for which we have an AOO 3.4 installation package. Oliver -- wow! -- a big undertaking! I applaud your efforts! Each entry provides a link to web page [6]. This web page is a currently empty landing page for our OOo 3.3 users. On this page we can provide information about our new home at the Apache Software Foundation and our AOO 3.4 release. From here we can direct our OOo 3.3 to our download page [7]. The reasons why I choose to provide a link to web page instead of providing direct download links are the following: - for platform Linux the static solution can not decide which package format is requested. - Rob and myself are in favor of such a landing page. From the OOo 3.3 update functionality the user can directly open this web page in the default browser. The XML document can be found at [4]. I also put it at [3] as file check.Update. Please start your testing. To test please perform the following steps: (step 1) stop your running OOo 3.3 instance inclusive quickstarter. (step 2) find in your OOo 3.3 installation the file version.ini (Windows) respectively the file versionrc (other platforms). (step 3) in this file replace in field UpdateURL the string [5] by [4] or by http://people.apache.org/~**orw/testupdateservice/check. **Update http://people.apache.org/%7Eorw/testupdateservice/check.Update . Please keep an existing query part, e.g. ?pkgformat=rpm. (step 4) start your OOo 3.3 from Marcus reply, it looks like the pkgfmt did not cause an issue, so this is good! Super work! I agree with Roberto's comment. We should unleash a subset of the entries in the real world and see what happens. (step 5a) check for an update manually via Menu Help - Check for Updates (step 5b) wait for the automatic update check configured via Menu Tools - Options - OpenOffice.org - Online Update. An available update should be notified on the right of your menu bar. Thanks in advance for your test efforts. Currently, I have no variants of the XML document ready. But, I am prepared to create the one or the other corresponding to your feedback. [6] http://www.openoffice.org/**projects/update36/** ProductUpdateService/index.**htmlhttp://www.openoffice.org/projects/update36/ProductUpdateService/index.html [7] http://www.openoffice.org/**downloadhttp://www.openoffice.org/download Best regards, Oliver. -- MzK The reports of my death are greatly exaggerated. -- Mark Twain
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 22.05.2012 18:21, Kay Schenk wrote: On Tue, May 22, 2012 at 6:21 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? I don't have any ideas at all in what would be included in such a script...so no help from me. And, I wonder if something like that was ever in operation. With no knowledge, I can't say. I assume that there were some server-side logic, but I am not sure. This logic would had investigated the HTTP GET request header fields User-Agent and Accept-Language to identify the OOo installation, e.g. German OOo 3.1 running on MacOS X. Then, I assume, it looked into its database for the newest OOo version for such an OOo installation. If it founds a newer version, e.g. German OOo 3.3 for MacOS X it assembles a corresponding XML document containing the data about this newer version. This XML document was then delivered as the HTTP GET response. Any thoughts/comments/**improvements/changes/...? It looks like we can go with the static solution as a short-term solution. Sounds good. this is reasonable and should work assuming infra can deal with handling the pkgfmt bits for Linux, for example. If we want to provide a direct download link for OOo 3.3 installation on Linux, this special handling will be needed. If we only want to provide a web page link from which the user have to manually download the needed package, this special handling won't be needed. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. I don't understand this one. Initiate update vs letting user choose and then do installation on their own? The XML document will contain element inst:update. Its attribute src will contain an URL. Its attribute type will determine, if the update function in OOo 3.3 will interpret the URL as an direct download link or as a link to a web page. Depending on the type the update function provides the user the function to trigger the download or to open the URL in the default browser. Rob and Roberto - as far as I have understand - were in favor of providing a link to a web page. I am completely open here. Thus, I think I will provide different variants of the XML document for testing. Best regards, Oliver.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 5/23/2012 05:16, Oliver-Rainer Wittmann wrote: Hi, [snip] Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. Answering your call for Windows volunteers: On my WV system, I'm running 3.3 (installed), 3.4 Beta (ooo-dev), and AOO 3.4 RC1 (parallel install). Playing with hosts should affect all of them. Thanks to playing with the wiki at an early stage, I already have a shortcut to my hosts file; for the nervous, there's a nice writeup at: http://en.wikipedia.org/wiki/Hosts_%28file%29 Let me know if I can help. /tj/
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 05/23/2012 02:16 AM, Oliver-Rainer Wittmann wrote: Hi, On 22.05.2012 18:21, Kay Schenk wrote: On Tue, May 22, 2012 at 6:21 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? I don't have any ideas at all in what would be included in such a script...so no help from me. And, I wonder if something like that was ever in operation. With no knowledge, I can't say. I assume that there were some server-side logic, but I am not sure. This logic would had investigated the HTTP GET request header fields User-Agent and Accept-Language to identify the OOo installation, e.g. German OOo 3.1 running on MacOS X. h...well I assumed all this was taken care by OOo itself in terms of identification combined with the XML feed in check.Update. So, I was not under the impression there was server-side involved. Then, I assume, it looked into its database for the newest OOo version for such an OOo installation. If it founds a newer version, e.g. German OOo 3.3 for MacOS X it assembles a corresponding XML document containing the data about this newer version. This XML document was then delivered as the HTTP GET response. Any thoughts/comments/**improvements/changes/...? It looks like we can go with the static solution as a short-term solution. Sounds good. this is reasonable and should work assuming infra can deal with handling the pkgfmt bits for Linux, for example. If we want to provide a direct download link for OOo 3.3 installation on Linux, this special handling will be needed. If we only want to provide a web page link from which the user have to manually download the needed package, this special handling won't be needed. OK, I'll trust what you say here. I guess we'll see what happens for others. We should just plan on directing Linux folks to a web page. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. I don't understand this one. Initiate update vs letting user choose and then do installation on their own? The XML document will contain element inst:update. Its attribute src will contain an URL. Its attribute type will determine, if the update function in OOo 3.3 will interpret the URL as an direct download link or as a link to a web page. Depending on the type the update function provides the user the function to trigger the download or to open the URL in the default browser. Rob and Roberto - as far as I have understand - were in favor of providing a link to a web page. I am completely open here. Thus, I think I will provide different variants of the XML document for testing. Best regards, Oliver. -- MzK The reports of my death are greatly exaggerated. -- Mark Twain
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 16.05.2012 13:24, Oliver-Rainer Wittmann wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.openoffice.org/ProductUpdateService/check.Update (plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. (B) dynamic solution: As the HTTP GET request contains all the information needed to identify the installed version performing the HTTP GET request - see [2], with some server-side logic an XML document could be dynamically created which servers the identified version. E.g.: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; inst:version- Apache OpenOffice 3.4/inst:version inst:buildid9590/inst:buildid inst:osLinux/inst:os inst:archx86/inst:arch inst:update type=application/octet-stream src=http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download; / /inst:description which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb If there is no AOO 3.4 for the identified OOo 3.3 the script should create the following XML document: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; /inst:description For this solution we need some server-side based script reacting on the above given URL, which can evaluate the provided information and can create XML documents as given above. [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol [2] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#summary_information_about_request_to_.3CUpdateURL.3E I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? Any thoughts/comments/improvements/changes/...? It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update service -- move the final XML document to [4]. -- ask ASF infrastructure team to redirect OOo 3.3 Update URL [5] to [4]. My goal is to have the update service for OOo 3.3 running at the end of next
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Tue, May 22, 2012 at 3:21 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 16.05.2012 13:24, Oliver-Rainer Wittmann wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.openoffice.org/ProductUpdateService/check.Update (plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. (B) dynamic solution: As the HTTP GET request contains all the information needed to identify the installed version performing the HTTP GET request - see [2], with some server-side logic an XML document could be dynamically created which servers the identified version. E.g.: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; inst:version- Apache OpenOffice 3.4/inst:version inst:buildid9590/inst:buildid inst:osLinux/inst:os inst:archx86/inst:arch inst:update type=application/octet-stream src=http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download; / /inst:description which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb If there is no AOO 3.4 for the identified OOo 3.3 the script should create the following XML document: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; /inst:description For this solution we need some server-side based script reacting on the above given URL, which can evaluate the provided information and can create XML documents as given above. [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol [2] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#summary_information_about_request_to_.3CUpdateURL.3E I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? Any thoughts/comments/improvements/changes/...? It looks like we can go with the static solution as a short-term solution. Thus, I will do the following: - Creation of a complete XML document - Include entries for at least one languages for which we have currently no AOO 3.4 installation package. - Providing the XML document and possible variants on [3] for testing and verification. - Call for volunteers to test the XML document at [3]. - Integrate feedback, if we want to have direct download links or links to a certain existing web page for manual download. - Activate the update
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Tue, May 22, 2012 at 6:21 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 16.05.2012 13:24, Oliver-Rainer Wittmann wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update(plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. (B) dynamic solution: As the HTTP GET request contains all the information needed to identify the installed version performing the HTTP GET request - see [2], with some server-side logic an XML document could be dynamically created which servers the identified version. E.g.: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description inst:version- Apache OpenOffice 3.4/inst:version inst:buildid9590/inst:**buildid inst:osLinux/inst:os inst:archx86/inst:arch inst:update type=application/octet-**stream src=http://sourceforge.net/**projects/openofficeorg.mirror/** files/stable/3.4.0/Apache_**OpenOffice_incubating_3.4.0_** Linux_x86_install-deb_en-US.**tar.gz/downloadhttp://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download / /inst:description which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb If there is no AOO 3.4 for the identified OOo 3.3 the script should create the following XML document: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description /inst:description For this solution we need some server-side based script reacting on the above given URL, which can evaluate the provided information and can create XML documents as given above. [1] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocolhttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol [2] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocol#summary_**information_about_request_to_.** 3CUpdateURL.3Ehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#summary_information_about_request_to_.3CUpdateURL.3E I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? I don't have any ideas at all in what would be
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 18.05.2012 22:55, Kay Schenk wrote: On Fri, May 18, 2012 at 1:09 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: [snip] This may be possible, because this information could also coded into the User-Agent field of the HTTP GET request. I don't get your meaning here. Sorry. The HTTP GET request contains information about the installed version making the request. The needed package format is currently coded as the URL query part. But, it could be also coded in the HTTP User-Agent field. How would we do that? The string for the HTTP User-Agent field in the HTTP GET request is assembled in the AOO source code. Thus, we can change it to everything we want ;-) OK, the next step, which we should deal with very cautiously given my past experiment, is to get infra to redirect update36.services.openoffice.** orghttp://update36.services.openoffice.org to the web server IP address. From my point of view we only should redirect the update URL of OOo 3.3 - namely update36. If it works fine, we can think of redirecting further update URLs from former versions. Right--and that was my thought as well. This is why I started out havign infor redirect update30, which, at it turns out, was a HUGE mistake because it didn't work the same as the future versions -- it did POST calls instead of GET. Thus, I propose to first go for OOo 3.3. If it is stable we can add OOo 3.2.1 and OOo 3.2 and ... - one after another. My personal opionion is that such redirects are not needed - but this is only my view. well, who knows. We could do it, and potentially, it would do no harm. It would be better if we could just try this with a very limited set of updates for the time being...maybe just 32 bit Linux German, for example, and take out the others for a bit and see what happens. The other thing is since we're still in the midst of the traffic for the new release, it would be better to wait at least another week. I know you've been after this for a while, and I completely understand, but well, results were REALLY disastrous with the update30 re-route -- I kid you not. Within 2 hours it incapacitated the Apache web server with the bad post calls -- I mean ALL of it -- all sites, and the redirect had to be backed out. I know we use get now and not post, but who would know this? Yes, we should wait for at least one week to establish the update service for OOo 3.3. And then only for OOo 3.3 I have a suggestion in the meantime, since I take it we would like some additional in house testing. You could post a new thread asking for testers who currently still have a 3.3. version (or maybe they have friends that do), tell them they'll need to do a local redirect -- via local /etc/hosts -- from update36.services.openoffice.org, to the web server IP, and then have them do the Check Update and see what happens. I actually tried to convince Windows friends to do this when I was working on this in early spring, but I just couldn't convince them they actually had an /etc/hosts and this would do no harm! :/ Maybe you'll have better luck. Yes, some further tests are needed. I will make a call, when the current XML document covers more installed versions. Best regards, Oliver. Maybe infra has like a different server we could use -- with a web server running on it, but not the main server. I'll try to find out tomorrow on #asinfra or you could get on there and find out. That is great that you are getting in contact with ASF infra regarding this issue. Thx. yes, I promise I will...but probably not until Monday. Best regards, Oliver. OK, thanks for all this. ps. If you figure out a way to do a generic URL redirect for all platforms and variants, let us know. This could be VERY helpful.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 20.05.2012 12:39, Andrea Pescetti wrote: On 18/05/2012 Oliver-Rainer Wittmann wrote: Thus, please let me in more detail describe what I am observing: For the static solution we would have a corresponding HTTP resource (our XML document) at URL X. I see that the HTTP GET requests made by the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the HTTP server. The response from the HTTP server contains the requested HTTP resource - in our case the XML document. OK, so if I understand properly: - We can serve the same XML file to all OpenOffice.org 3.3 installations - Each OpenOffice.org 3.3 installation will parse the file and find out whether updates are available or not - inst_id as in http://people.apache.org/~orw/testupdateservice/33 contains the language, so this can be exploited too - Updates can be served as download files or web pages Yes. We can try out several options in advance. I will work on the XML document to get it more or less complete. Than volunteers can change the Update URL in their installation and see what happens. This is very good since it would allow to: - Properly cache the XML file to avoid excessive traffic - Languages not covered by OpenOffice 3.4 can be set not to display updates for the time being (e.g., the fi version won't report that updates are available until 3.4.1, which will include fi, is released) - We can take advantage of redirecting to a (possibly localized, since we can take advantage of it) URL and we can delegate information provision and download logic to it I hope so. If, I understand your observations correct, you need to remove the query part from the update URL in order to assure that the update functionality recieves the XML document. Is this correct? This is basically the same problem as handling the http://www.openoffce.org/?lang=it requests. I made some test yesterday, maybe https://issues.apache.org/jira/browse/INFRA-4624 can be useful (mod_rewrite handles the query fragment in a special way). ASF infrastructure team just told me that they can establish difference redirects on different query parts. I would definitely suggest to use a separate machine to serve that traffic, unless we are really sure that the www.openoffice.org web server won't suffer from it. For the re-established AOO 3.4 update service - see other thread - the ASF infrastructure team told me that the server would handle the amount of HTTP GET requests. The HTTP GET request contains information about the installed version making the request. The needed package format is currently coded as the URL query part. But, it could be also coded in the HTTP User-Agent field. OK, but we can completely ignore/reset it right? I.e., the problem could be solved by providing a generic XML file and delegating to OpenOffice.org 3.3 all handling. Yes, I think for former versions - like OOo 3.3 - we can just ignore it. But, we could not provide direct download link for Linux installations as we can not figure out which package format is needed. Thus, I put an URL of a webpage in the XML document for Linux installations Yes, we should wait for at least one week to establish the update service for OOo 3.3. And then only for OOo 3.3 OK, and here comes the issue of serving them through MirrorBrain or not (when we believed that the only way to distribute updates was unassisted downloads, there was some consensus on using MirrorBrain for updates). On one hand, as I wrote, I consider MirrorBrain an important community resource and I hope that they are available to help this project too, and that it is possible to identify a role for them in the current setup. On the other hand, SourceForge so far worked quite well... The good thing is that we can be completely granular, like (just inventing) using the nice capabilities of partial local mirroring offered by MirrorBrain to distribute non-English updates through its network and English updates through SourceForge. Here, I am able to support whatever is possible this the XML document. We can provide direct download links or special webpage URLs for each entry in the XML document. But, as stated above, we can not provide direct download links for Linux installation from my point of view. Best regards, Oliver.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Mon, May 21, 2012 at 8:01 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 20.05.2012 12:39, Andrea Pescetti wrote: On 18/05/2012 Oliver-Rainer Wittmann wrote: Thus, please let me in more detail describe what I am observing: For the static solution we would have a corresponding HTTP resource (our XML document) at URL X. I see that the HTTP GET requests made by the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the HTTP server. The response from the HTTP server contains the requested HTTP resource - in our case the XML document. OK, so if I understand properly: - We can serve the same XML file to all OpenOffice.org 3.3 installations - Each OpenOffice.org 3.3 installation will parse the file and find out whether updates are available or not - inst_id as in http://people.apache.org/~orw/**testupdateservice/33http://people.apache.org/%7Eorw/testupdateservice/33contains the language, so this can be exploited too - Updates can be served as download files or web pages Yes. We can try out several options in advance. I will work on the XML document to get it more or less complete. Than volunteers can change the Update URL in their installation and see what happens. This is very good since it would allow to: - Properly cache the XML file to avoid excessive traffic - Languages not covered by OpenOffice 3.4 can be set not to display updates for the time being (e.g., the fi version won't report that updates are available until 3.4.1, which will include fi, is released) - We can take advantage of redirecting to a (possibly localized, since we can take advantage of it) URL and we can delegate information provision and download logic to it I hope so. If, I understand your observations correct, you need to remove the query part from the update URL in order to assure that the update functionality recieves the XML document. Is this correct? This is basically the same problem as handling the http://www.openoffce.org/?**lang=it http://www.openoffce.org/?lang=itrequests. I made some test yesterday, maybe https://issues.apache.org/**jira/browse/INFRA-4624https://issues.apache.org/jira/browse/INFRA-4624can be useful (mod_rewrite handles the query fragment in a special way). ASF infrastructure team just told me that they can establish difference redirects on different query parts. This is good news! I wasn't sure about the granularity of something like this... So, if they can deal with re-routing the pkgfmt business, we would be good for a direct to page. Great! I would definitely suggest to use a separate machine to serve that traffic, unless we are really sure that the www.openoffice.org web server won't suffer from it. For the re-established AOO 3.4 update service - see other thread - the ASF infrastructure team told me that the server would handle the amount of HTTP GET requests. The HTTP GET request contains information about the installed version making the request. The needed package format is currently coded as the URL query part. But, it could be also coded in the HTTP User-Agent field. OK, but we can completely ignore/reset it right? I.e., the problem could be solved by providing a generic XML file and delegating to OpenOffice.org 3.3 all handling. Yes, I think for former versions - like OOo 3.3 - we can just ignore it. But, we could not provide direct download link for Linux installations as we can not figure out which package format is needed. Thus, I put an URL of a webpage in the XML document for Linux installations Yes, we should wait for at least one week to establish the update service for OOo 3.3. And then only for OOo 3.3 OK, and here comes the issue of serving them through MirrorBrain or not (when we believed that the only way to distribute updates was unassisted downloads, there was some consensus on using MirrorBrain for updates). On one hand, as I wrote, I consider MirrorBrain an important community resource and I hope that they are available to help this project too, and that it is possible to identify a role for them in the current setup. On the other hand, SourceForge so far worked quite well... The good thing is that we can be completely granular, like (just inventing) using the nice capabilities of partial local mirroring offered by MirrorBrain to distribute non-English updates through its network and English updates through SourceForge. Here, I am able to support whatever is possible this the XML document. We can provide direct download links or special webpage URLs for each entry in the XML document. But, as stated above, we can not provide direct download links for Linux installation from my point of view. Best regards, Oliver. -- MzK The reports of my death are greatly exaggerated.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 18/05/2012 Oliver-Rainer Wittmann wrote: Thus, please let me in more detail describe what I am observing: For the static solution we would have a corresponding HTTP resource (our XML document) at URL X. I see that the HTTP GET requests made by the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the HTTP server. The response from the HTTP server contains the requested HTTP resource - in our case the XML document. OK, so if I understand properly: - We can serve the same XML file to all OpenOffice.org 3.3 installations - Each OpenOffice.org 3.3 installation will parse the file and find out whether updates are available or not - inst_id as in http://people.apache.org/~orw/testupdateservice/33 contains the language, so this can be exploited too - Updates can be served as download files or web pages This is very good since it would allow to: - Properly cache the XML file to avoid excessive traffic - Languages not covered by OpenOffice 3.4 can be set not to display updates for the time being (e.g., the fi version won't report that updates are available until 3.4.1, which will include fi, is released) - We can take advantage of redirecting to a (possibly localized, since we can take advantage of it) URL and we can delegate information provision and download logic to it If, I understand your observations correct, you need to remove the query part from the update URL in order to assure that the update functionality recieves the XML document. Is this correct? This is basically the same problem as handling the http://www.openoffce.org/?lang=it requests. I made some test yesterday, maybe https://issues.apache.org/jira/browse/INFRA-4624 can be useful (mod_rewrite handles the query fragment in a special way). I would definitely suggest to use a separate machine to serve that traffic, unless we are really sure that the www.openoffice.org web server won't suffer from it. The HTTP GET request contains information about the installed version making the request. The needed package format is currently coded as the URL query part. But, it could be also coded in the HTTP User-Agent field. OK, but we can completely ignore/reset it right? I.e., the problem could be solved by providing a generic XML file and delegating to OpenOffice.org 3.3 all handling. Yes, we should wait for at least one week to establish the update service for OOo 3.3. And then only for OOo 3.3 OK, and here comes the issue of serving them through MirrorBrain or not (when we believed that the only way to distribute updates was unassisted downloads, there was some consensus on using MirrorBrain for updates). On one hand, as I wrote, I consider MirrorBrain an important community resource and I hope that they are available to help this project too, and that it is possible to identify a role for them in the current setup. On the other hand, SourceForge so far worked quite well... The good thing is that we can be completely granular, like (just inventing) using the nice capabilities of partial local mirroring offered by MirrorBrain to distribute non-English updates through its network and English updates through SourceForge. Regards, Andrea.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 17.05.2012 03:13, Kay Schenk wrote: On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 16.05.2012 21:58, Kay Schenk wrote: [snip] One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. From my point of view this should not be a problem as it seems that the HTTP server neglects the URL query part in such a static case. I am not an expert here, please correct me if I am wrong. well, I'll try it again...I have several versions to play with...I seem to recall I had to manually delete the pkgfmt business and then I got it to work. I have recently tested on Ubuntu with an old developer snapshot of AOO 3.4. It just worked fine, even with an update URL having the query part. OK...I recall I had to take this off and then it did work with getting me a URL page. I am not sure, if we both about the same. Thus, please let me in more detail describe what I am observing: For the static solution we would have a corresponding HTTP resource (our XML document) at URL X. I see that the HTTP GET requests made by the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the HTTP server. The response from the HTTP server contains the requested HTTP resource - in our case the XML document. Then the XML document is parsed by the update functionality in AOO 3.4 resp. OOo 3.3. Two cases needs to be distinguish here: (1) XML document is in the simple form - only containing XML element inst:description with corresponding childs. (2) XML document is in the atom feed form In case (1) the update functionality checks the following three conditions: (a) inst:os content matches the one of the installed version (b) inst:arch content mathes the one of installed version (c) inst:buildid contant - BuildID of newer version - is greater than the BuildID of the installed version. Possible values for inst:os and inst:arch can be found in [1]. If the conditions hold further information are read - inst:version and inst:update - and the user is presented the information that an update is available together with the update URL. If the conditions do not hold - e.g. empty inst:description element the user is presented the information that installed version is up to date. In case (2) the update functionality searches for entries which matches the condition that attribute term of element category matches the one of installed version. Then action as in case (1) are performed on each entry until an entry matches the above conditions. If, I understand your observations correct, you need to remove the query part from the update URL in order to assure that the update functionality recieves the XML document. Is this correct? [1] https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/sal/rtl/source/macro.hxx When I browse to http://update36.services.**openoffice.org/** ProductUpdateService/check.**Update?pkgformat=debhttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=debusing the FireFox it provides me the content of the XML document. BTW, I have already updated the XML document as you suggested. As I forgot to include an entry for Linux 32bit in my first try you may be hit my first XML document. I'll get back to you on this later today. Ok, thanks. OK, well since I am at 3.4., I can't help much with this without editing the XML doc yo have out there I'm afraid, so I will take your word for what you say works and just hope we can get on with things. Yes. When you are testing with a released AOO 3.4 you at least need to increase the value of inst:buildid in the XML document to get the information from the update functionality that an update is available. I think I will make a discussion thread to totally ditch the pkgfmt business from Linux update URLs. It would considerably simplify our lives. Do you mean for future versions of AOO? yes...this would be best I think. Installing on Linux automatically can be tricky if you're not root anyway. No harm in just shuttling folks to a page to choose something and then do the install in my mind. I never tried the automatic installation on Linux. I will hae a look in my Ubuntu VM which has OOo 3.3 installed. This may be possible, because this information could also coded into the User-Agent field of the HTTP GET request. I don't get your meaning here. Sorry. The HTTP GET request contains information about the installed version making the request. The needed package format is currently coded as the URL query part. But, it could be also coded in the HTTP User-Agent field. OK, the next step, which we should deal with very cautiously given my past experiment, is to get infra to redirect
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Fri, May 18, 2012 at 1:09 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 17.05.2012 03:13, Kay Schenk wrote: On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 16.05.2012 21:58, Kay Schenk wrote: [snip] One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. From my point of view this should not be a problem as it seems that the HTTP server neglects the URL query part in such a static case. I am not an expert here, please correct me if I am wrong. well, I'll try it again...I have several versions to play with...I seem to recall I had to manually delete the pkgfmt business and then I got it to work. I have recently tested on Ubuntu with an old developer snapshot of AOO 3.4. It just worked fine, even with an update URL having the query part. OK...I recall I had to take this off and then it did work with getting me a URL page. I am not sure, if we both about the same. Thus, please let me in more detail describe what I am observing: For the static solution we would have a corresponding HTTP resource (our XML document) at URL X. I see that the HTTP GET requests made by the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the HTTP server. The response from the HTTP server contains the requested HTTP resource - in our case the XML document. Then the XML document is parsed by the update functionality in AOO 3.4 resp. OOo 3.3. Two cases needs to be distinguish here: (1) XML document is in the simple form - only containing XML element inst:description with corresponding childs. (2) XML document is in the atom feed form In case (1) the update functionality checks the following three conditions: (a) inst:os content matches the one of the installed version (b) inst:arch content mathes the one of installed version (c) inst:buildid contant - BuildID of newer version - is greater than the BuildID of the installed version. Possible values for inst:os and inst:arch can be found in [1]. If the conditions hold further information are read - inst:version and inst:update - and the user is presented the information that an update is available together with the update URL. If the conditions do not hold - e.g. empty inst:description element the user is presented the information that installed version is up to date. In case (2) the update functionality searches for entries which matches the condition that attribute term of element category matches the one of installed version. Then action as in case (1) are performed on each entry until an entry matches the above conditions. If, I understand your observations correct, you need to remove the query part from the update URL in order to assure that the update functionality recieves the XML document. Is this correct? well this is what I remember...yes. After I did that, I did get the go to URL approach to work. I was running 3.3, can't recall what the build number was. [1] https://svn.apache.org/repos/**asf/incubator/ooo/trunk/main/** sal/rtl/source/macro.hxxhttps://svn.apache.org/repos/asf/incubator/ooo/trunk/main/sal/rtl/source/macro.hxx When I browse to http://update36.services.**ope**noffice.org/**http://openoffice.org/** ProductUpdateService/check.Update?pkgformat=debhttp://** update36.services.openoffice.**org/ProductUpdateService/** check.Update?pkgformat=debhttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=deb **using the FireFox it provides me the content of the XML document. BTW, I have already updated the XML document as you suggested. As I forgot to include an entry for Linux 32bit in my first try you may be hit my first XML document. I'll get back to you on this later today. Ok, thanks. OK, well since I am at 3.4., I can't help much with this without editing the XML doc yo have out there I'm afraid, so I will take your word for what you say works and just hope we can get on with things. Yes. When you are testing with a released AOO 3.4 you at least need to increase the value of inst:buildid in the XML document to get the information from the update functionality that an update is available. I think I will make a discussion thread to totally ditch the pkgfmt business from Linux update URLs. It would considerably simplify our lives. Do you mean for future versions of AOO? yes...this would be best I think. Installing on Linux automatically can be tricky if you're not root anyway. No harm in just shuttling folks to a page to choose something and then do the install in my mind. I never tried the automatic installation on Linux. I will hae a look in my Ubuntu VM which has OOo 3.3 installed.
[UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.openoffice.org/ProductUpdateService/check.Update (plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. (B) dynamic solution: As the HTTP GET request contains all the information needed to identify the installed version performing the HTTP GET request - see [2], with some server-side logic an XML document could be dynamically created which servers the identified version. E.g.: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; inst:version- Apache OpenOffice 3.4/inst:version inst:buildid9590/inst:buildid inst:osLinux/inst:os inst:archx86/inst:arch inst:update type=application/octet-stream src=http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download; / /inst:description which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb If there is no AOO 3.4 for the identified OOo 3.3 the script should create the following XML document: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; /inst:description For this solution we need some server-side based script reacting on the above given URL, which can evaluate the provided information and can create XML documents as given above. [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol [2] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#summary_information_about_request_to_.3CUpdateURL.3E I would prefer the static solution as a short-term one which could be working next week. For the dynamic solution a script is needed. I have no experience in programming such a script. Is there a volunteer who would take over this task? Any thoughts/comments/improvements/changes/...? Best regards, Oliver. ?xml version=1.0 encoding=utf-8? feed xmlns=http://www.w3.org/2005/Atom; xml:lang=en-US titleProduct Update Feed/title updated2012-05-08T12:00:00Z/updated author nameApache OpenOffice project (incubating)/name urihttp://openoffice.org/uri /author !-- German - Windows -- entry titleUpdate available/title !-- IMPORTANT: category MUST be equal with UpdateID in version.ini -- category term=OpenOffice.org_3_de label=Apache OpenOffice update/ content type=application/xml inst:description xmlns:inst=http://installation.openoffice.org/description; inst:idOpenOffice.org_3_de/inst:id inst:version- Apache
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update(plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. Oliver-- Hi. OK, a dumb question...have you ascertained that this doc actually works? That is, have you tested it with some sort of URL redirect? Right now, we have an area on the web server that could house this...in /projects/update36/ProductUpdateService If you overwrite check.Update with this file, and do a local host setup, your own /etc/hosts, and redirect update36.services.openoffice.org to 140.211.11.131 you could test it out One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. Your analysis about just leading linux folks to the url of a page for an update is great, but what to do about the existing information? Anyway, copy your doc over to the web server, setup the redirect, and let us know how things go. (B) dynamic solution: As the HTTP GET request contains all the information needed to identify the installed version performing the HTTP GET request - see [2], with some server-side logic an XML document could be dynamically created which servers the identified version. E.g.: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description inst:version- Apache OpenOffice 3.4/inst:version inst:buildid9590/inst:**buildid inst:osLinux/inst:os inst:archx86/inst:arch inst:update type=application/octet-**stream src= http://sourceforge.net/**projects/openofficeorg.mirror/** files/stable/3.4.0/Apache_**OpenOffice_incubating_3.4.0_** Linux_x86_install-deb_en-US.**tar.gz/downloadhttp://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.0/Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_en-US.tar.gz/download / /inst:description which would serve a OOo 3.3, en-US, Linux 32bit, packgage format deb If there is no AOO 3.4 for the identified OOo 3.3 the script should create the following XML document: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description /inst:description For this solution
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 16.05.2012 19:27, Kay Schenk wrote: On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update(plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. Oliver-- Hi. OK, a dumb question...have you ascertained that this doc actually works? That is, have you tested it with some sort of URL redirect? I am testing with my test XML documents on http://people.apache.org/~orw/testupdateservice/ I am not using redirects. Instead I am adjusting my version.ini resp. versionrc files. Right now, we have an area on the web server that could house this...in /projects/update36/ProductUpdateService If you overwrite check.Update with this file, and do a local host setup, your own /etc/hosts, and redirect update36.services.openoffice.org to 140.211.11.131 you could test it out I will test it. One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. From my point of view this should not be a problem as it seems that the HTTP server neglects the URL query part in such a static case. I am not an expert here, please correct me if I am wrong. Your analysis about just leading linux folks to the url of a page for an update is great, but what to do about the existing information? Sorry, but I do not know what you mean by what to do about the existing information? Anyway, copy your doc over to the web server, setup the redirect, and let us know how things go. Yes, I will. Best regards, Oliver.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
On 05/16/2012 12:48 PM, Oliver-Rainer Wittmann wrote: Hi, On 16.05.2012 19:27, Kay Schenk wrote: On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update(plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. Oliver-- Hi. OK, a dumb question...have you ascertained that this doc actually works? That is, have you tested it with some sort of URL redirect? I am testing with my test XML documents on http://people.apache.org/~orw/testupdateservice/ I am not using redirects. Instead I am adjusting my version.ini resp. versionrc files. Right now, we have an area on the web server that could house this...in /projects/update36/ProductUpdateService If you overwrite check.Update with this file, and do a local host setup, your own /etc/hosts, and redirect update36.services.openoffice.org to 140.211.11.131 you could test it out I will test it. One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. From my point of view this should not be a problem as it seems that the HTTP server neglects the URL query part in such a static case. I am not an expert here, please correct me if I am wrong. well, I'll try it again...I have several versions to play with...I seem to recall I had to manually delete the pkgfmt business and then I got it to work. I'll get back to you on this later today. I think I will make a discussion thread to totally ditch the pkgfmt business from Linux update URLs. It would considerably simplify our lives. Your analysis about just leading linux folks to the url of a page for an update is great, but what to do about the existing information? Sorry, but I do not know what you mean by what to do about the existing information? Anyway, copy your doc over to the web server, setup the redirect, and let us know how things go. Yes, I will. Best regards, Oliver. -- 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: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 16.05.2012 21:58, Kay Schenk wrote: [snip] One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. From my point of view this should not be a problem as it seems that the HTTP server neglects the URL query part in such a static case. I am not an expert here, please correct me if I am wrong. well, I'll try it again...I have several versions to play with...I seem to recall I had to manually delete the pkgfmt business and then I got it to work. I have recently tested on Ubuntu with an old developer snapshot of AOO 3.4. It just worked fine, even with an update URL having the query part. When I browse to http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=deb using the FireFox it provides me the content of the XML document. BTW, I have already updated the XML document as you suggested. As I forgot to include an entry for Linux 32bit in my first try you may be hit my first XML document. I'll get back to you on this later today. Ok, thanks. I think I will make a discussion thread to totally ditch the pkgfmt business from Linux update URLs. It would considerably simplify our lives. Do you mean for future versions of AOO? This may be possible, because this information could also coded into the User-Agent field of the HTTP GET request. Best regards, Oliver.
Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Hi, On 16.05.2012 19:27, Kay Schenk wrote: On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: as our release AOO 3.4 is out now for more than a week I think it would make sense to reactivate a simple update service for installed OOo 3.3 versions. I have already seen a post on the users mailing list that the update functionality is not working in OOo 3.3. I assume that corresponding posts also exist in the forum. From my point of view it is time to let our OOo 3.3 users know via the update functionality that we have released AOO 3.4. The update URL for OOo 3.3 is: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update(plus a query part ?pkgfmt=pkgformat for non-Windows platforms) As this URL resolves to nothing, the user currently gets the following response from the update functionality in OOo 3.3: Status: Checking for an update failed. Description: Error reading data from the network. Server error message: Could not read status line: An existing connection was forcibly closed by the remote host. There are two solutions: (A) static solution: Provide an XML document similar to the one which is attached when an HTTP GET request to the above given URL is made. The attached XML document contains an atom feed according to [1] Currently, it only contains entries for: - German, Windows - German, MacOS X - German, Linux, 32bit - German, Linux, 64bit - English-US, Windows I hope I got the inst:os and inst:arch content right for all the platforms. For Windows and MacOS we could directly provide download links. Thus, the update functionality can download it and install it on corresponding user demand. For Linux we can not distinguish the different needed package formats in this static solution - as far as I know. Thus, a landing page can be given here. The update functionality can open it in the user's default browser on corresponding user demand. In the attached XML document I included our AOO 3.4 release announcement page as this landing page - this is only a proposal. The final XML document needs to be extended by entries for all possible combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit, Linux 64bit) for each language which we had released for AOO 3.4. It would be also be possible to include more combinations for which we have no package. We could create a special landing page for these which state that AOO 3.4 is out and that the user might want to have a look, if one of the provided packages would fit her/his needs. For this solution we need to provide the XML document at the above given URL. Oliver-- Hi. OK, a dumb question...have you ascertained that this doc actually works? That is, have you tested it with some sort of URL redirect? Right now, we have an area on the web server that could house this...in /projects/update36/ProductUpdateService If you overwrite check.Update with this file, and do a local host setup, your own /etc/hosts, and redirect update36.services.openoffice.org to 140.211.11.131 you could test it out One of the problems we will run into, esp for Linux (I don't know about other platforms) is that the user has a appended pkgfmt already on the update URL, so in my experimenting, the update call failed because an acceptable package was not found. Your analysis about just leading linux folks to the url of a page for an update is great, but what to do about the existing information? Anyway, copy your doc over to the web server, setup the redirect, and let us know how things go. I have updated the XML document on /projects/update36/ProductUpdateService. I have tested on an Ubuntu 11.10 in a VM with an fresh installed OOo 3.3 en-US and with the redirect in /etc/hosts as you had suggested. The result of my test is that the update functionality in OOo 3.3 informs me about an available update. I could browse via the corresponding button in the update functionality to the given URL which is http://www.openoffice.org/news/aoo34.html - see the updated XML document. Best regards, Oliver.
