Re: Anything we can do about premature redistribution?
2014-04-23 1:37 GMT+02:00 Andrea Pescetti pesce...@apache.org: On 22/04/2014 Roberto Galoppini wrote: 2014-04-22 0:14 GMT+02:00 Andrea Pescetti: http://www.openoffice.org/download/devbuilds.html Andrea are you saying we should re-route RCs download requests coming from all referrals (but openoffice.org and sourceforge.net) to that page? That would be the proposal, yes. Add apache.org to the whitelisted referrals. Please confirm my understand is correct and provide me with the exact directory/files so that I can ask our SiteOps to implement that right away I don't think we already have the files online. The files to be redirected are the Release Candidates, and I may be wrong but I assume that RC4 is not yet on SourceForge and will be uploaded during or immediately after the vote. Ok, I'm assuming those files will be in a directory called 4.1? Please let me know, so that I can move with this plan accordingly. Roberto During this period (lasting a few days) we don't want to allow downloads until we send out the official release news. Reason: we may (and we did it already) decide to push a last-minute fix even when a release has been approved but is not distributed yet. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/7/14, Rob Weir robw...@apache.org wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. This is implied on the 'Beta' label that was added on softpedia. Every beta product assumes that bugs, even critical could surface. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? At the bottom of the website it says Feedback. Of course you could legally contact the parent company about the issue but I dont think that's necessary. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/7/14, Rob Weir robw...@apache.org wrote: On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote: Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ I think we can create a blog explaining the voting procedure and make clear where we are in the process and that it is the RC of the Beta only. Or maybe a disclaimer in the voting thread email? Next time we could say something like: Note: All Apache releases require a vote of the PMC lasting at least 72-hours. We do not officially release until after that vote has concluded. We appreciate the enthusiasm of our users and 3rd party distributors and their efforts to publicize our releases and share them with a broader audience. But we ask that you do not publicize a release until the vote has concluded and the vote results posted. This is for the safety of the users. It is always possible for a last minute defect to be reported in a Release Candidate causing us to cancel an in-progress vote. in fact this has occurred before. So be safe and wait for the release process to conclude. I'm guessing that they hear about the RC from the email list, not the wiki, so it might make sense to put a message like this in the vote email. Not sure email would be as effective as on the website (in this case, the cWiki page). Do softpedia find out about these RCs from the ML or the wiki? -Rob But I don't know if this would really help to avoid confusion. Juergen Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
2014-04-22 0:14 GMT+02:00 Andrea Pescetti pesce...@apache.org: On 19/04/2014 Roberto Galoppini wrote: Our aim I believe it's to expand our userbase, redirecting them to an openoffice page explaining which are the options might be a good thing. We can reuse, and possibly reword, this page then: http://www.openoffice.org/download/devbuilds.html This is where people trying to download a yet unapproved RC would land, so the content, disclaimers and links seem quite appropriate. Andrea are you saying we should re-route RCs download requests coming from all referrals (but openoffice.org and sourceforge.net) to that page? Please confirm my understand is correct and provide me with the exact directory/files so that I can ask our SiteOps to implement that right away, I'll do that once I'll get the green light. Thanks, Roberto Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 22/04/2014 Roberto Galoppini wrote: 2014-04-22 0:14 GMT+02:00 Andrea Pescetti: http://www.openoffice.org/download/devbuilds.html Andrea are you saying we should re-route RCs download requests coming from all referrals (but openoffice.org and sourceforge.net) to that page? That would be the proposal, yes. Add apache.org to the whitelisted referrals. Please confirm my understand is correct and provide me with the exact directory/files so that I can ask our SiteOps to implement that right away I don't think we already have the files online. The files to be redirected are the Release Candidates, and I may be wrong but I assume that RC4 is not yet on SourceForge and will be uploaded during or immediately after the vote. During this period (lasting a few days) we don't want to allow downloads until we send out the official release news. Reason: we may (and we did it already) decide to push a last-minute fix even when a release has been approved but is not distributed yet. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 19/04/2014 Roberto Galoppini wrote: Our aim I believe it's to expand our userbase, redirecting them to an openoffice page explaining which are the options might be a good thing. We can reuse, and possibly reword, this page then: http://www.openoffice.org/download/devbuilds.html This is where people trying to download a yet unapproved RC would land, so the content, disclaimers and links seem quite appropriate. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 02/04/2014 Roberto Galoppini wrote: softpedia.com ... passes traffic through our download redirector flow ... we can indeed redirect this traffic by referrer to a different landing page if one is provided. Can't we just serve a 403? It's their problem, not ours. It's not rude at all, it's a way to protect our users: if we don't want that our unreleased versions are purported for real releases, we need that users only access them from a page on apache.org, on openoffice.org or e-mail until we release them. So matching the HTTP referer and serving a 403 unless it comes from *.apache.org , *.openoffice.org or is empty seems the best solution to me. If we really want to be extra-polite, http://www.openoffice.org/download/devbuilds.html should be scary enough for casual users. Of course, if this is a manual operation that must be done when we enter RC phase and undone after release, and only the SourceForge staff can do that, then this becomes a bit complex. Or can the project members who have access to the SourceForge area enable/disable the protection with no need for external help? Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
2014-04-19 16:21 GMT+02:00 Andrea Pescetti pesce...@apache.org: On 02/04/2014 Roberto Galoppini wrote: softpedia.com ... passes traffic through our download redirector flow ... we can indeed redirect this traffic by referrer to a different landing page if one is provided. Can't we just serve a 403? It's their problem, not ours. It's not rude at all, it's a way to protect our users: if we don't want that our unreleased versions are purported for real releases, we need that users only access them from a page on apache.org, on openoffice.org or e-mail until we release them. So matching the HTTP referer and serving a 403 unless it comes from *. apache.org , *.openoffice.org or is empty seems the best solution to me. If we really want to be extra-polite, http://www.openoffice.org/ download/devbuilds.html should be scary enough for casual users. We could take the chance to educate those users about which is the last available version, though. Reading Softpedia site it's clear they are not providing the end-user with a way to pick up 4.0.1 or 4.1 beta, and the title is just confusing Apache OpenOffice.org 4.0.1 / 4.1.0 Beta. Our aim I believe it's to expand our userbase, redirecting them to an openoffice page explaining which are the options might be a good thing. Thoughts? Of course, if this is a manual operation that must be done when we enter RC phase and undone after release, and only the SourceForge staff can do that, then this becomes a bit complex. Or can the project members who have access to the SourceForge area enable/disable the protection with no need for external help? So far regex-based redirect based on referral need to be managed by SiteOps, but I can make sure we get what we want. Roberto Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 4/2/14 11:19 PM, Marcus (OOo) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in the same location. Yes, that's doable in the way Kay described. And yes,
Re: Anything we can do about premature redistribution?
2014-04-03 8:52 GMT+02:00 Jürgen Schmidt jogischm...@gmail.com: On 4/2/14 11:19 PM, Marcus (OOo) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download
Re: Anything we can do about premature redistribution?
On 4/3/14 12:09 PM, Roberto Galoppini wrote: 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt jogischm...@gmail.com: On 4/2/14 11:19 PM, Marcus (OOo) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But
Re: Anything we can do about premature redistribution?
On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in the same location.
Re: Anything we can do about premature redistribution?
2014-04-03 13:09 GMT+02:00 Rob Weir robw...@apache.org: On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then
Re: Anything we can do about premature redistribution?
Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini: 2014-04-03 13:09 GMT+02:00 Rob Weirrobw...@apache.org: On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay
Re: Anything we can do about premature redistribution?
2014-04-03 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de: Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini: 2014-04-03 13:09 GMT+02:00 Rob Weirrobw...@apache.org: On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de : Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever
Re: Anything we can do about premature redistribution?
Am 04/03/2014 01:09 PM, schrieb Rob Weir: On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in
Re: Anything we can do about premature redistribution?
Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt: On 4/3/14 12:09 PM, Roberto Galoppini wrote: 2014-04-03 8:52 GMT+02:00 Jürgen Schmidtjogischm...@gmail.com: On 4/2/14 11:19 PM, Marcus (OOo) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come
Re: Anything we can do about premature redistribution?
2014-04-03 21:44 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de: Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt: On 4/3/14 12:09 PM, Roberto Galoppini wrote: 2014-04-03 8:52 GMT+02:00 Jürgen Schmidtjogischm...@gmail.com: On 4/2/14 11:19 PM, Marcus (OOo) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo) marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located
Re: Anything we can do about premature redistribution?
2014-04-01 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? Roberto Thanks Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus
Re: Anything we can do about premature redistribution?
On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini roberto.galopp...@gmail.com wrote: 2014-04-01 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? Roberto Roberto -- thanks for all this investigation. Should we assume that this caution should only be applied to: http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/ assuming this area would always be used for betas? Thanks Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is
Re: Anything we can do about premature redistribution?
Am 04/02/2014 06:52 PM, schrieb Kay Schenk: On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini roberto.galopp...@gmail.com wrote: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? Roberto Roberto -- thanks for all this investigation. Should we assume that this caution should only be applied to: http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/ assuming this area would always be used for betas? Without other opinions I would assume the same. For Beta or any other pre-final releases this would help. However, the problem remains when it comes to a final release that is located one subdir up in .../files/: We want to protect the release builds until we have really announced it officially. So, IMHO it has to be a more generic solution like the staging-bit or a substitute text (see my other mail to
Re: Anything we can do about premature redistribution?
Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in the same location. I'm wondering if the staging bit can help as best solution. I would expect that the new location is not public *and* not known *and* not useable/functional for the normal non-admin user *until* we remove the bit. Am I right? Thanks Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with
Re: Anything we can do about premature redistribution?
2014-04-02 21:15 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in the same location. Yes, that's doable in the way Kay described. And yes, we would add the text and disable downloads. I'm wondering if the staging bit can help as best solution. I would expect that the new location
Re: Anything we can do about premature redistribution?
Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.orgwrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.orgor the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Our SiteOps team looked into this, here our findings: Great :-) One provider (chip.de) serves via Akamai CDN, one provider ( computerbase.de) serves via their own FTP server, and softpedia.com lists SourceForge as an external mirror and passes traffic through our download redirector flow (not direct to a mirror). The first two cases are things we can't control. In the third case, we can indeed redirect this traffic by referrer to a different landing page if one is provided. Maybe we want to have a openoffice.org page explaining that's a release-candidate and it's served only for testing purposes and its use on a daily basis it is not recommended. How does that sound? I'm pretty sure that these kind of downloaders do not care about disclaimers - less then ever when located somewhere else. ;-) So, either we disable the entire download for the specific timeframe or at least a text as substitute (like This release is not yet public. Please stay tuned and come back when it is announced.). But this text has then to be on Sourceforge in the same location. Yes, that's doable in the way Kay described. And yes, we would add the text and disable downloads. Just to be sure, is this limited to a special subdir like
Re: Anything we can do about premature redistribution?
Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? To be honest, I don't care about a few days were a special set of domains were not able to access for a few days. For me they are a bit too enthusiastic. And as you said in a previous post it's to protect us as best as possible. +1 This seems sufficient to me. @Roberto: Do you see a technical way to return a predefined error message when the release builds are already on Sourceforge but not yet officially released and published? Thanks Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
+1 I like this way Am 31.03.2014 22:48, schrieb Rob Weir: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? -Rob Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? -Rob Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir robw...@apache.org wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de: Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. Thanks for heads up Marcus, sorry for not having noticed this thread before. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? I need the domain list and I'll check out with our SiteOps if that's doable. Feel free to send me a list with a direct message. - chip.de - computerbase.de - softpedia.com This would be the domains from this thread that could be blocked from downloading from Sourceforge. Obviously needs to be extended in the future. Remember, the next will happen with the AOO 4.1.0 RC. ;-) *Of course*, this is just for the time frame as long as the new version is not officially announced. As soon as the release is public, the block will be removed. @all: I think this could help to limit the downloadability like we want to see until the official release. What you think? I don't know. Won't this just cause confusion? They point to the files, go to test them, see the links don't work, and then get weird errors and spend an hour trying to debug it. We don't want to needlessly annoy them, since their only fault is enthusiasm. Is there a way we can give a useful error message in this case like, This version of Apache OpenOffice has not yet been officially released. Links to these files are disallowed until the release is officially approved or something like that? -Rob +1 This seems sufficient to me. Marcus Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: Anything we can do about premature redistribution?
Am 03/13/2014 10:01 PM, schrieb Marcus (OOo): Am 03/09/2014 06:08 PM, schrieb Marcus (OOo): Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Do you see a chance to get this implemented? I think it could help to stop some bad websites to do bad things with our software. @Roberto: Maybe you haven't seen this up to now. It would be great if you can tell us if it's possible to exclude some domains / IP addresses from downloading our software? Then we can exclude requester that we don't want (e.g., malware distributors). Also in time frames with Beta or RC releases it can help us to steer who is able and when it is possible to download OpenOffice like we want to see until the real release date is reached. Thanks Marcus Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/9/14 8:49 PM, Marcus (OOo) wrote: Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. it is there as well, hdu started the synch when the bits where ready on the Apache server for some further testing purposes (especially upload performance). And of course to have them in place in time for today. It was probably a little bit early but independent where we upload the bits they will be grabbed immediately. Which is not necessarily bad if they would do their job a little bit better ;-) There was no official release announcement. Juergen In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 10.03.2014 08:32, Jürgen Schmidt wrote: On 3/9/14 8:49 PM, Marcus (OOo) wrote: Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. it is there as well, hdu started the synch when the bits where ready on the Apache server for some further testing purposes (especially upload performance). And of course to have them in place in time for today. It was probably a little bit early but independent where we upload the bits they will be grabbed immediately. Which is not necessarily bad if they would do their job a little bit better ;-) There was no official release announcement. Is it possible to upload to some kind of staging area on sourceforge that is not accessible to the public? Keep the bits there until our vote has finished and them move them to the download area? -Andre Juergen In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Am 03/10/2014 08:32 AM, schrieb Jürgen Schmidt: On 3/9/14 8:49 PM, Marcus (OOo) wrote: Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. it is there as well, hdu started the synch when the bits where ready on the Apache server for some further testing purposes (especially upload performance). And of course to have them in place in time for today. I've expected this. But what scares me is that I cannot see anything about the Beta even when I'm logged-in as admin. Marcus It was probably a little bit early but independent where we upload the bits they will be grabbed immediately. Which is not necessarily bad if they would do their job a little bit better ;-) There was no official release announcement. Juergen In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Am 03/10/2014 08:57 AM, schrieb Andre Fischer: On 10.03.2014 08:32, Jürgen Schmidt wrote: On 3/9/14 8:49 PM, Marcus (OOo) wrote: Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. it is there as well, hdu started the synch when the bits where ready on the Apache server for some further testing purposes (especially upload performance). And of course to have them in place in time for today. It was probably a little bit early but independent where we upload the bits they will be grabbed immediately. Which is not necessarily bad if they would do their job a little bit better ;-) There was no official release announcement. Is it possible to upload to some kind of staging area on sourceforge that is not accessible to the public? Keep the bits there until our vote has finished and them move them to the download area? Yes, you can create a new folder and give it a staging bit. Then you can use it (e.g., upload things into it) but it is not visible to the outside. Marcus In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Am 03/08/2014 12:29 AM, schrieb Vladislav Stevanovic: When somebody want to download beta version of AOO it will be good aproach to show pop-up dialog with warnings that this is not stable version and it only for testing. We can not stopped other to write what they write about AOO but we can protect potential users with info dialog when they press link for downloading beta version. That will be done on the download webpage - when the Beta is actually available. Marcus 2014-03-08 0:09 GMT+01:00 Andrea Pescettipesce...@apache.org: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.netdomains, then the project would effectively be in control. The embargo could be lifted just after the release. Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: Anything we can do about premature redistribution?
On 09/03/2014 Kay Schenk wrote: The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones Correct? No. The link Rob posted at the beginning of this discussion http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml will redirect you for download to something under http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/4.1.0-beta/binaries/en-US/ which, I assume, is the location we will advertise on the main download page for Beta downloads (otherwise Infra will be quite upset if we link to Apache servers!). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Anything we can do about premature redistribution?
Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote: Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ I think we can create a blog explaining the voting procedure and make clear where we are in the process and that it is the RC of the Beta only. But I don't know if this would really help to avoid confusion. Juergen Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote: Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ I think we can create a blog explaining the voting procedure and make clear where we are in the process and that it is the RC of the Beta only. Or maybe a disclaimer in the voting thread email? Next time we could say something like: Note: All Apache releases require a vote of the PMC lasting at least 72-hours. We do not officially release until after that vote has concluded. We appreciate the enthusiasm of our users and 3rd party distributors and their efforts to publicize our releases and share them with a broader audience. But we ask that you do not publicize a release until the vote has concluded and the vote results posted. This is for the safety of the users. It is always possible for a last minute defect to be reported in a Release Candidate causing us to cancel an in-progress vote. in fact this has occurred before. So be safe and wait for the release process to conclude. I'm guessing that they hear about the RC from the email list, not the wiki, so it might make sense to put a message like this in the vote email. -Rob But I don't know if this would really help to avoid confusion. Juergen Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/7/14 4:33 PM, Rob Weir wrote: On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote: Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ I think we can create a blog explaining the voting procedure and make clear where we are in the process and that it is the RC of the Beta only. Or maybe a disclaimer in the voting thread email? Next time we could say something like: Note: All Apache releases require a vote of the PMC lasting at least 72-hours. We do not officially release until after that vote has concluded. We appreciate the enthusiasm of our users and 3rd party distributors and their efforts to publicize our releases and share them with a broader audience. But we ask that you do not publicize a release until the vote has concluded and the vote results posted. This is for the safety of the users. It is always possible for a last minute defect to be reported in a Release Candidate causing us to cancel an in-progress vote. in fact this has occurred before. So be safe and wait for the release process to conclude. I'm guessing that they hear about the RC from the email list, not the wiki, so it might make sense to put a message like this in the vote email. +1, already marked and I will add it the next time. But for this time we can put this text in a blog. Opinions? Juergen -Rob But I don't know if this would really help to avoid confusion. Juergen Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
A water-mark on new documents that directs people to find official distributions on the web site? The water-mark will be taken off when AOO is out of beta and an official release is available. At the least this would require those who want to just redistribute know enough programming to make it inconvenient for them. On Fri, Mar 7, 2014 at 7:37 AM, Jürgen Schmidt jogischm...@gmail.comwrote: On 3/7/14 4:33 PM, Rob Weir wrote: On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote: Hi, On 07.03.2014 15:22, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? softpedia is not the only one: - http://www.chip.de/downloads/OpenOffice_14324674.html - http://www.computerbase.de/downloads/office/ I think we can create a blog explaining the voting procedure and make clear where we are in the process and that it is the RC of the Beta only. Or maybe a disclaimer in the voting thread email? Next time we could say something like: Note: All Apache releases require a vote of the PMC lasting at least 72-hours. We do not officially release until after that vote has concluded. We appreciate the enthusiasm of our users and 3rd party distributors and their efforts to publicize our releases and share them with a broader audience. But we ask that you do not publicize a release until the vote has concluded and the vote results posted. This is for the safety of the users. It is always possible for a last minute defect to be reported in a Release Candidate causing us to cancel an in-progress vote. in fact this has occurred before. So be safe and wait for the release process to conclude. I'm guessing that they hear about the RC from the email list, not the wiki, so it might make sense to put a message like this in the vote email. +1, already marked and I will add it the next time. But for this time we can put this text in a blog. Opinions? Juergen -Rob But I don't know if this would really help to avoid confusion. Juergen Best regards, Oliver. -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 3/7/2014 6:22 AM, Rob Weir wrote: Evidently we're already released, on some websites at least: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml Also, what of the Editor's review? It is derived from the IBM Lotus Symphony suite of applications... - not correct Under the hood, Apache OpenOffice is translated in over 170 languages... - not correct It is also very important to mention here that the well known LibreOffice open source office suite is based on the source code of this application. - hmmm - correct, but, not the traditional LO formulation Ever since the Oracle Corporation acquired the Sun Microsystems company, work on Apache OpenOffice ceased, and various developers who worked on the project decided to create a new project, named LibreOffice. - neither correct nor pertinent Because of this, LibreOffice is now the main choice for any Linux distribution developer who wants to pre-install a complete and open source office suite application in their operating system(s). How much do we care about this? The risk, I suppose, is on Softpedia, that we could find a last-minute defect in the NOTICE or other legal files, and they find themselves distributing a package that is not correct. But the practical risk there is small. The greater risk is to users, that we find a last-minute fatal bug that causes us to cancel the vote, but there are versions of the Release Candidate still floating around. That can hurt the AOO reputation if that happened. I'm not sure we can prevent this from happening, and still have an open and transparent voting process. But maybe there is something we can do to discourage it? -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847
Re: Anything we can do about premature redistribution?
On 7 March 2014 22:30, Andrew Rist andrew.r...@oracle.com wrote: It is derived from the IBM Lotus Symphony suite of applications... - not correct https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato suggests this is not an unfair statement. Indeed, just rebasing on the Symphony code was seriously considered. Ever since the Oracle Corporation acquired the Sun Microsystems company, work on Apache OpenOffice ceased, and various developers who worked on the project decided to create a new project, named LibreOffice. - neither correct nor pertinent That's ridiculously wrong, to the point of warranting formal messages of correction from both projects. In general, I would suggest asking nicely as the very first approach, when the beta is in fact approved and ready. - d. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
When somebody want to download beta version of AOO it will be good aproach to show pop-up dialog with warnings that this is not stable version and it only for testing. We can not stopped other to write what they write about AOO but we can protect potential users with info dialog when they press link for downloading beta version. Regards, Wlada 2014-03-08 0:09 GMT+01:00 Andrea Pescetti pesce...@apache.org: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.netdomains, then the project would effectively be in control. The embargo could be lifted just after the release. Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
