Re: Anything we can do about premature redistribution?
On 3/7/14, Rob Weir wrote: > On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt > 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?
On 3/7/14, 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. 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?
2014-04-23 1:37 GMT+02:00 Andrea Pescetti : > 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 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?
2014-04-22 0:14 GMT+02:00 Andrea Pescetti : > 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 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?
2014-04-19 16:21 GMT+02:00 Andrea Pescetti : > 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 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?
Am 04/03/2014 11:12 PM, schrieb Roberto Galoppini: 2014-04-03 21:44 GMT+02:00 Marcus (OOo): 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 Schmidt: 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): Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) 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 downlo
Re: Anything we can do about premature redistribution?
2014-04-03 21:44 GMT+02:00 Marcus (OOo) : > 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 Schmidt: >>> >>> 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): >> >> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: >>> >>>2014-04-01 21:30 GMT+02:00 Marcus (OOo): >>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir > wrote: > > >> On Mon, Mar 31, 2014 at 4:43 PM, Marcus >> (OOo) >> >> 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. ;-) >
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 Schmidt: 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): Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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
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) wrote: Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini: 2014-04-02 21:15 GMT+02:00 Marcus (OOo): Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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 downloa
Re: Anything we can do about premature redistribution?
2014-04-03 21:30 GMT+02:00 Marcus (OOo) : > Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini: > > 2014-04-03 13:09 GMT+02:00 Rob Weir: >> >> On Wed, Apr 2, 2014 at 5: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): > > Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: >> >>2014-04-01 21:30 GMT+02:00 Marcus (OOo): >> >>> >>> >>>Am 03/31/2014 11:56 PM, schrieb Kay Schenk: >>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir 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)>> >: >>> >>> 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. >>> >> >> >>Rem
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 Weir: On Wed, Apr 2, 2014 at 5: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): Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir 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): 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 : > On Wed, Apr 2, 2014 at 5: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): > >> > >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: > >>> > >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo): > > > Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > > > > >On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir > > 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): > > > > >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 > >>> > >
Re: Anything we can do about premature redistribution?
On Wed, Apr 2, 2014 at 5: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): >> >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: >>> >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > >On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir > wrote: > >> >>On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) >> >>> wrote: >>> >>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > >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
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 : > >> 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): > Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: > > 2014-04-01 21:30 GMT+02:00 Marcus (OOo): >> >> Am 03/31/2014 11:56 PM, schrieb Kay Schenk: >>> >>>On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir >>> wrote: >>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) > wrote: > > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: >> >>2014-03-28 21:24 GMT+01:00 Marcus (OOo): >> >>> >>>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 mess
Re: Anything we can do about premature redistribution?
2014-04-03 8:52 GMT+02:00 Jürgen Schmidt : > 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): > >> > >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: > >>> > >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo): > > Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > > >On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir > > wrote: > > > >> > >>On Mon, Mar 31, 2014 at 4:43 PM, Marcus > >> (OOo) > >> > >>> wrote: > >>> > >>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: > > 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > > > > >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
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): >> >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: >>> >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > >On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir > wrote: > >> >>On Mon, Mar 31, 2014 at 4:43 PM, Marcus >> (OOo) >> >>> wrote: >>> >>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > >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
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): Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: 2014-04-01 21:30 GMT+02:00 Marcus (OOo): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirwrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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 ".../files/milestones/"? Or also, additionally for ".../files/"? I'm wondering if the "stag
Re: Anything we can do about premature redistribution?
2014-04-02 21:15 GMT+02:00 Marcus (OOo) : > Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: > > 2014-04-01 21:30 GMT+02:00 Marcus (OOo): >> >> Am 03/31/2014 11:56 PM, schrieb Kay Schenk: >>> >>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: >>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) > wrote: > > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: >> >> 2014-03-28 21:24 GMT+01:00 Marcus (OOo): >> >>> >>> 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
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): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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 Beta or RC releases it can help us to steer who is able and when it
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): Am 03/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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 Roberto). Marcus Then we can exclude requester that we don't want
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) : > > > Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > > > On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: > >> > >> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) > >>> wrote: > >>> > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: > > 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > > > > 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 > diff
Re: Anything we can do about premature redistribution?
2014-04-01 21:30 GMT+02:00 Marcus (OOo) : > Am 03/31/2014 11:56 PM, schrieb Kay Schenk: > > On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: >> >> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) >>> wrote: >>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > > 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 fram
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) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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/31/2014 11:56 PM, schrieb Kay Schenk: On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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?
On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir wrote: > On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) > wrote: > > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: > > > >> 2014-03-28 21:24 GMT+01:00 Marcus (OOo): > >> > >>> 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?
On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) wrote: > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: > >> 2014-03-28 21:24 GMT+01:00 Marcus (OOo): >> >>> 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?
Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: 2014-03-28 21:24 GMT+01:00 Marcus (OOo): 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?
2014-03-28 21:24 GMT+01:00 Marcus (OOo) : > 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. Roberto > > 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?
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?
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) 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/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) 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?
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) 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?
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) >> 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?
Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo) 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
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?
On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo) 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?
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 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.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?
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? 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?
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 : > 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?
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?
On 7 March 2014 22:30, Andrew Rist 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?
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?
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 wrote: > On 3/7/14 4:33 PM, Rob Weir wrote: > > On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt > 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/14 4:33 PM, Rob Weir wrote: > On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt 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 Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt 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: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?
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
