Re: Anything we can do about premature redistribution?

2014-04-23 Thread Roberto Galoppini
2014-04-23 1:37 GMT+02:00 Andrea Pescetti pesce...@apache.org:

 On 22/04/2014 Roberto Galoppini wrote:

 2014-04-22 0:14 GMT+02:00 Andrea Pescetti:

 http://www.openoffice.org/download/devbuilds.html

 Andrea are you saying we should re-route RCs download requests coming from
 all referrals (but openoffice.org and sourceforge.net) to that page?


 That would be the proposal, yes. Add apache.org to the whitelisted
 referrals.


  Please confirm my understand is correct and provide me with the exact
 directory/files so that I can ask our SiteOps to implement that right away


 I don't think we already have the files online. The files to be redirected
 are the Release Candidates, and I may be wrong but I assume that RC4 is not
 yet on SourceForge and will be uploaded during or immediately after the
 vote.


Ok, I'm assuming those files will be in a directory called 4.1? Please let
me know, so that I can move with this plan accordingly.

Roberto



 During this period (lasting a few days) we don't want to allow downloads
 until we send out the official release news. Reason: we may (and we did it
 already) decide to push a last-minute fix even when a release has been
 approved but is not distributed yet.


 Regards,
   Andrea.

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: Anything we can do about premature redistribution?

2014-04-23 Thread Alexandro Colorado
On 3/7/14, Rob Weir robw...@apache.org wrote:
 Evidently we're already released, on some websites at least:

 http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml

 How much do we care about this?   The risk, I suppose, is on
 Softpedia, that we could find a last-minute defect in the NOTICE or
 other legal files, and they find themselves distributing a package
 that is not correct.  But the practical risk there is small.

 The greater risk is to users, that we find a last-minute fatal bug
 that causes us to cancel the vote, but there are versions of the
 Release Candidate still floating around.  That can hurt the AOO
 reputation if that happened.

This is implied on the 'Beta' label that was added on softpedia. Every
beta product assumes that bugs, even critical could surface.


 I'm not sure we can prevent this from happening, and still have an
 open and transparent voting process.  But maybe there is something we
 can do to discourage it?

At the bottom of the website it says  Feedback. Of course you could
legally contact the parent company about the issue but I dont think
that's necessary.


 -Rob

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-04-23 Thread Alexandro Colorado
On 3/7/14, Rob Weir robw...@apache.org wrote:
 On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com
 wrote:
 On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
 Hi,

 On 07.03.2014 15:22, Rob Weir wrote:
 Evidently we're already released, on some websites at least:

 http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml


 How much do we care about this?   The risk, I suppose, is on
 Softpedia, that we could find a last-minute defect in the NOTICE or
 other legal files, and they find themselves distributing a package
 that is not correct.  But the practical risk there is small.

 The greater risk is to users, that we find a last-minute fatal bug
 that causes us to cancel the vote, but there are versions of the
 Release Candidate still floating around.  That can hurt the AOO
 reputation if that happened.

 I'm not sure we can prevent this from happening, and still have an
 open and transparent voting process.  But maybe there is something we
 can do to discourage it?



 softpedia is not the only one:
 - http://www.chip.de/downloads/OpenOffice_14324674.html
 - http://www.computerbase.de/downloads/office/


 I think we can create a blog explaining the voting procedure and make
 clear where we are in the process and that it is the RC of the Beta only.


 Or maybe a disclaimer in the voting thread email?   Next time we could
 say something like:

 Note:   All Apache releases require a vote of the PMC lasting at
 least 72-hours.  We do not officially release until after that vote
 has concluded.   We appreciate the enthusiasm of our users and 3rd
 party distributors and their efforts to publicize our releases and
 share them with a broader audience.  But we ask that you do not
 publicize a release until the vote has concluded and the vote results
 posted.  This is for the safety of the users.  It is always possible
 for a last minute defect to be reported in a Release Candidate causing
 us to cancel an in-progress vote.  in fact this has occurred before.
 So be safe and wait for the release process to conclude.

 I'm guessing that they hear about the RC from the email list, not the
 wiki, so it might make sense to put a message like this in the vote
 email.

Not sure email would be as effective as on the website (in this case,
the cWiki page). Do softpedia find out about these RCs from the ML or
the wiki?


 -Rob


 But I don't know if this would really help to avoid confusion.

 Juergen



 Best regards, Oliver.

 -Rob

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-04-22 Thread Roberto Galoppini
2014-04-22 0:14 GMT+02:00 Andrea Pescetti pesce...@apache.org:

 On 19/04/2014 Roberto Galoppini wrote:

 Our aim I believe it's to expand our userbase, redirecting them to an
 openoffice page explaining which are the options might be a good thing.


 We can reuse, and possibly reword, this page then:
 http://www.openoffice.org/download/devbuilds.html

 This is where people trying to download a yet unapproved RC would land, so
 the content, disclaimers and links seem quite appropriate.


Andrea are you saying we should re-route RCs download requests coming from
all referrals (but openoffice.org and sourceforge.net) to that page?

Please confirm my understand is correct and provide me with the exact
directory/files so that I can ask our SiteOps to implement that right away,
I'll do that once I'll get the green light.

Thanks,

Roberto





 Regards,
   Andrea.

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: Anything we can do about premature redistribution?

2014-04-22 Thread 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. 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-21 Thread 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.


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 Thread 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.


Of course, if this is a manual operation that must be done when we enter 
RC phase and undone after release, and only the SourceForge staff can do 
that, then this becomes a bit complex. Or can the project members who 
have access to the SourceForge area enable/disable the protection with 
no need for external help?


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-04-19 Thread Roberto Galoppini
2014-04-19 16:21 GMT+02:00 Andrea Pescetti pesce...@apache.org:

 On 02/04/2014 Roberto Galoppini wrote:

 softpedia.com ... passes traffic through our download redirector flow
 ... we can indeed redirect this traffic by referrer to a

 different landing page if one is provided.


 Can't we just serve a 403? It's their problem, not ours. It's not rude at
 all, it's a way to protect our users: if we don't want that our unreleased
 versions are purported for real releases, we need that users only access
 them from a page on apache.org, on openoffice.org or e-mail until we
 release them.

 So matching the HTTP referer and serving a 403 unless it comes from *.
 apache.org , *.openoffice.org or is empty seems the best solution to me.
 If we really want to be extra-polite, http://www.openoffice.org/
 download/devbuilds.html should be scary enough for casual users.


We could take the chance to educate those users about which is the last
available version, though. Reading Softpedia site it's clear they are not
providing the end-user with a way to pick up 4.0.1 or 4.1 beta, and the
title is just confusing Apache OpenOffice.org 4.0.1 / 4.1.0 Beta.

Our aim I believe it's to expand our userbase, redirecting them to an
openoffice page explaining which are the options might be a good thing.

Thoughts?




 Of course, if this is a manual operation that must be done when we enter
 RC phase and undone after release, and only the SourceForge staff can do
 that, then this becomes a bit complex. Or can the project members who have
 access to the SourceForge area enable/disable the protection with no need
 for external help?


So far regex-based redirect based on referral need to be managed by
SiteOps, but I can make sure we get what we want.

Roberto




 Regards,
   Andrea.


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: Anything we can do about premature redistribution?

2014-04-03 Thread 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)marcus.m...@wtnet.de:

 Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org   
 wrote:


On Mon, Mar 31, 2014 at 4:43 PM, Marcus
 (OOo)marcus.m...@wtnet.de

 wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/



   Apache-OpenOffice-253.shtml



  Or maybe a disclaimer in the voting thread email?




   Andrew's comments show clearly that these editors do not
 care
 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their
 downloads.

   They


   link to our binaries hosted on SourceForge (which is fine). Just

 thinking loud, but if it was possible (on the Sourceforge side) to
 deny
 all download requests that do not come from the
 openoffice.orgor

   the


   sourceforge.net domains, then the project would effectively be in

 control. The embargo could be lifted just after the release.


   For me this sounds like a great idea.

 Maybe we should start with denying all download requests
 that some

   from


   these bad websites.


 @Roberto:
 Can you tell us if this possible? If yes, is it much effort for
 you?


   Do you see a chance to get this implemented? I think it could
 help to
 stop some bad websites to do bad things with our software.


   @Roberto:
 Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this
 thread
 before.




   It would be great if you can tell us if it's possible to exclude
 some
 domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if
 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked
 from
 downloading from Sourceforge. Obviously needs to be extended in the

   future.

   Remember, the next will happen with the AOO 4.1.0 RC. ;-)

 *Of course*, this is just for the time frame as long as the new
 version

   is

   not officially announced. As soon as the release is public, the
 block

   will

   be removed.

 @all:
 I think this could help to limit the downloadability like we
 want to
 see
 until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to
 the
 files, go to test them, see the links don't work, and then get weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?


   To be honest, I don't care about a few days were a special set of
 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us as
 best
 as possible.


+1 This seems sufficient to me.



 @Roberto:
 Do you see a technical way to return a predefined error message
 when the
 release builds are already on Sourceforge but not yet officially
 released
 and published?


 Our SiteOps team looked into this, here our findings:


 Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (
 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge as
 an
 external mirror and passes traffic through our download redirector flow
 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to a
 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's
 served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever when located somewhere else. ;-)

 So, either we disable the entire download for the specific timeframe
 or at
 least a text as substitute (like This release is not yet public. Please
 stay tuned and come back when it is announced.). But this text has
 then to
 be on Sourceforge in the same location.


 Yes, that's doable in the way Kay described. And yes, 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Roberto Galoppini
2014-04-03 8:52 GMT+02:00 Jürgen Schmidt jogischm...@gmail.com:

 On 4/2/14 11:19 PM, Marcus (OOo) wrote:
  Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
  2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:
 
  Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
 
2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:
 
Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
 
 On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
  wrote:
 
 
 On Mon, Mar 31, 2014 at 4:43 PM, Marcus
  (OOo)marcus.m...@wtnet.de
 
  wrote:
 
Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
 
 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:
 
 
 Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
 
 
 Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
 
 
 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
 
 
 Rob Weir wrote:
 
 
 http://linux.softpedia.com/get/Office/Office-Suites/
 
 
 
Apache-OpenOffice-253.shtml
 
 
 
   Or maybe a disclaimer in the voting thread email?
 
 
 
 
Andrew's comments show clearly that these editors do not
  care
  to be
  careful or factual, or even read those disclaimers,
  unfortunately.
 
  We can be successful only if we manage to block their
  downloads.
 
They
 
 
link to our binaries hosted on SourceForge (which is fine). Just
 
  thinking loud, but if it was possible (on the Sourceforge side)
 to
  deny
  all download requests that do not come from the
  openoffice.orgor
 
the
 
 
sourceforge.net domains, then the project would effectively be
 in
 
  control. The embargo could be lifted just after the release.
 
 
For me this sounds like a great idea.
 
  Maybe we should start with denying all download requests
  that some
 
from
 
 
these bad websites.
 
 
  @Roberto:
  Can you tell us if this possible? If yes, is it much effort
 for
  you?
 
 
Do you see a chance to get this implemented? I think it
 could
  help to
  stop some bad websites to do bad things with our software.
 
 
@Roberto:
  Maybe you haven't seen this up to now.
 
 
Thanks for heads up Marcus, sorry for not having noticed this
  thread
  before.
 
 
 
 
It would be great if you can tell us if it's possible to
 exclude
  some
  domains / IP addresses from downloading our software?
 
 
I need the domain list and I'll check out with our SiteOps if
  that's
  doable. Feel free to send me a list with a direct message.
 
 
 
  - chip.de
  - computerbase.de
  - softpedia.com
 
  This would be the domains from this thread that could be blocked
  from
  downloading from Sourceforge. Obviously needs to be extended in
 the
 
future.
 
Remember, the next will happen with the AOO 4.1.0 RC. ;-)
 
  *Of course*, this is just for the time frame as long as the new
  version
 
is
 
not officially announced. As soon as the release is public, the
  block
 
will
 
be removed.
 
  @all:
  I think this could help to limit the downloadability like we
  want to
  see
  until the official release. What you think?
 
 
I don't know.  Won't this just cause confusion?  They point to
  the
  files, go to test them, see the links don't work, and then get
 weird
  errors and spend an hour trying to debug it.  We don't want to
  needlessly annoy them, since their only fault is enthusiasm.   Is
  there a way we can give a useful error message in this case like,
  This version of Apache OpenOffice has not yet been officially
  released.  Links to these files are disallowed until the release is
  officially approved  or something like that?
 
 
To be honest, I don't care about a few days were a special set of
  domains
  were not able to access for a few days. For me they are a bit too
  enthusiastic. And as you said in a previous post it's to protect us
 as
  best
  as possible.
 
 
 +1 This seems sufficient to me.
 
 
 
  @Roberto:
  Do you see a technical way to return a predefined error message
  when the
  release builds are already on Sourceforge but not yet officially
  released
  and published?
 
 
  Our SiteOps team looked into this, here our findings:
 
 
  Great :-)
 
 
One provider (chip.de) serves via Akamai CDN, one provider (
  computerbase.de)
  serves via their own FTP server, and softpedia.com lists SourceForge
 as
  an
  external mirror and passes traffic through our download redirector
 flow
  (not direct to a mirror).
 
  The first two cases are things we can't control.
 
  In the third case, we can indeed redirect this traffic by referrer to
 a
  different landing page if one is provided. Maybe we want to have a
  openoffice.org page explaining that's a release-candidate and it's
  served
  only for testing purposes and its use on a daily basis it is not
  recommended.
 
  How does that sound?
 
 
  I'm pretty sure that these kind of downloaders do not care about
  disclaimers - less then ever when located somewhere else. ;-)
 
  So, either we disable the entire download 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Jürgen Schmidt
On 4/3/14 12:09 PM, Roberto Galoppini wrote:
 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt jogischm...@gmail.com:
 
 On 4/2/14 11:19 PM, Marcus (OOo) wrote:
 Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

 Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
 wrote:


On Mon, Mar 31, 2014 at 4:43 PM, Marcus
 (OOo)marcus.m...@wtnet.de

 wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/



   Apache-OpenOffice-253.shtml



  Or maybe a disclaimer in the voting thread email?




   Andrew's comments show clearly that these editors do not
 care
 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their
 downloads.

   They


   link to our binaries hosted on SourceForge (which is fine). Just

 thinking loud, but if it was possible (on the Sourceforge side)
 to
 deny
 all download requests that do not come from the
 openoffice.orgor

   the


   sourceforge.net domains, then the project would effectively be
 in

 control. The embargo could be lifted just after the release.


   For me this sounds like a great idea.

 Maybe we should start with denying all download requests
 that some

   from


   these bad websites.


 @Roberto:
 Can you tell us if this possible? If yes, is it much effort
 for
 you?


   Do you see a chance to get this implemented? I think it
 could
 help to
 stop some bad websites to do bad things with our software.


   @Roberto:
 Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this
 thread
 before.




   It would be great if you can tell us if it's possible to
 exclude
 some
 domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if
 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked
 from
 downloading from Sourceforge. Obviously needs to be extended in
 the

   future.

   Remember, the next will happen with the AOO 4.1.0 RC. ;-)

 *Of course*, this is just for the time frame as long as the new
 version

   is

   not officially announced. As soon as the release is public, the
 block

   will

   be removed.

 @all:
 I think this could help to limit the downloadability like we
 want to
 see
 until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to
 the
 files, go to test them, see the links don't work, and then get
 weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?


   To be honest, I don't care about a few days were a special set of
 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us
 as
 best
 as possible.


+1 This seems sufficient to me.



 @Roberto:
 Do you see a technical way to return a predefined error message
 when the
 release builds are already on Sourceforge but not yet officially
 released
 and published?


 Our SiteOps team looked into this, here our findings:


 Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (
 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge
 as
 an
 external mirror and passes traffic through our download redirector
 flow
 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to
 a
 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's
 served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever when located somewhere else. ;-)

 So, either we disable the entire download for the specific timeframe
 or at
 least a text as substitute (like This release is not yet public.
 Please
 stay tuned and come back when it is announced.). But 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Rob Weir
On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) marcus.m...@wtnet.de wrote:
 Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:

 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

 Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:


On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
 wrote:


On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de

 wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/



   Apache-OpenOffice-253.shtml




  Or maybe a disclaimer in the voting thread email?




   Andrew's comments show clearly that these editors do not
 care

 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their
 downloads.

   They



   link to our binaries hosted on SourceForge (which is fine). Just


 thinking loud, but if it was possible (on the Sourceforge side) to

 deny
 all download requests that do not come from the
 openoffice.orgor

   the



   sourceforge.net domains, then the project would effectively be in


 control. The embargo could be lifted just after the release.



   For me this sounds like a great idea.


 Maybe we should start with denying all download requests that
 some

   from



   these bad websites.



 @Roberto:
 Can you tell us if this possible? If yes, is it much effort for
 you?


   Do you see a chance to get this implemented? I think it could

 help to
 stop some bad websites to do bad things with our software.


   @Roberto:

 Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this

 thread
 before.




   It would be great if you can tell us if it's possible to exclude

 some
 domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if

 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked
 from
 downloading from Sourceforge. Obviously needs to be extended in the

   future.


   Remember, the next will happen with the AOO 4.1.0 RC. ;-)


 *Of course*, this is just for the time frame as long as the new
 version

   is


   not officially announced. As soon as the release is public, the
 block


   will


   be removed.


 @all:
 I think this could help to limit the downloadability like we want to
 see
 until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to the

 files, go to test them, see the links don't work, and then get weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?


   To be honest, I don't care about a few days were a special set of

 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us as
 best
 as possible.


+1 This seems sufficient to me.



 @Roberto:
 Do you see a technical way to return a predefined error message when
 the
 release builds are already on Sourceforge but not yet officially
 released
 and published?


 Our SiteOps team looked into this, here our findings:


 Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (

 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge as
 an
 external mirror and passes traffic through our download redirector flow
 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to a
 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's
 served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever when located somewhere else. ;-)

 So, either we disable the entire download for the specific timeframe or
 at
 least a text as substitute (like This release is not yet public. Please
 stay tuned and come back when it is announced.). But this text has then
 to
 be on Sourceforge in the same location.


 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Roberto Galoppini
2014-04-03 13:09 GMT+02:00 Rob Weir robw...@apache.org:

 On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) marcus.m...@wtnet.de wrote:
  Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
 
  2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:
 
  Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
 
2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:
 
 
Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
 
 
 On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
  wrote:
 
 
 On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)
 marcus.m...@wtnet.de
 
  wrote:
 
Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
 
 
 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:
 
 
 Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
 
 
 Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
 
 
 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
 
 
 Rob Weir wrote:
 
 
 http://linux.softpedia.com/get/Office/Office-Suites/
 
 
 
Apache-OpenOffice-253.shtml
 
 
 
 
   Or maybe a disclaimer in the voting thread email?
 
 
 
 
Andrew's comments show clearly that these editors do not
  care
 
  to be
  careful or factual, or even read those disclaimers,
  unfortunately.
 
  We can be successful only if we manage to block their
  downloads.
 
They
 
 
 
link to our binaries hosted on SourceForge (which is fine). Just
 
 
  thinking loud, but if it was possible (on the Sourceforge side)
 to
 
  deny
  all download requests that do not come from the
  openoffice.orgor
 
the
 
 
 
sourceforge.net domains, then the project would effectively be
 in
 
 
  control. The embargo could be lifted just after the release.
 
 
 
For me this sounds like a great idea.
 
 
  Maybe we should start with denying all download requests that
  some
 
from
 
 
 
these bad websites.
 
 
 
  @Roberto:
  Can you tell us if this possible? If yes, is it much effort
 for
  you?
 
 
Do you see a chance to get this implemented? I think it
 could
 
  help to
  stop some bad websites to do bad things with our software.
 
 
@Roberto:
 
  Maybe you haven't seen this up to now.
 
 
Thanks for heads up Marcus, sorry for not having noticed this
 
  thread
  before.
 
 
 
 
It would be great if you can tell us if it's possible to
 exclude
 
  some
  domains / IP addresses from downloading our software?
 
 
I need the domain list and I'll check out with our SiteOps if
 
  that's
  doable. Feel free to send me a list with a direct message.
 
 
 
  - chip.de
  - computerbase.de
  - softpedia.com
 
  This would be the domains from this thread that could be blocked
  from
  downloading from Sourceforge. Obviously needs to be extended in
 the
 
future.
 
 
Remember, the next will happen with the AOO 4.1.0 RC. ;-)
 
 
  *Of course*, this is just for the time frame as long as the new
  version
 
is
 
 
not officially announced. As soon as the release is public, the
  block
 
 
will
 
 
be removed.
 
 
  @all:
  I think this could help to limit the downloadability like we want
 to
  see
  until the official release. What you think?
 
 
I don't know.  Won't this just cause confusion?  They point to
 the
 
  files, go to test them, see the links don't work, and then get
 weird
  errors and spend an hour trying to debug it.  We don't want to
  needlessly annoy them, since their only fault is enthusiasm.   Is
  there a way we can give a useful error message in this case like,
  This version of Apache OpenOffice has not yet been officially
  released.  Links to these files are disallowed until the release is
  officially approved  or something like that?
 
 
To be honest, I don't care about a few days were a special set of
 
  domains
  were not able to access for a few days. For me they are a bit too
  enthusiastic. And as you said in a previous post it's to protect us
 as
  best
  as possible.
 
 
 +1 This seems sufficient to me.
 
 
 
  @Roberto:
  Do you see a technical way to return a predefined error message when
  the
  release builds are already on Sourceforge but not yet officially
  released
  and published?
 
 
  Our SiteOps team looked into this, here our findings:
 
 
  Great :-)
 
 
One provider (chip.de) serves via Akamai CDN, one provider (
 
  computerbase.de)
  serves via their own FTP server, and softpedia.com lists SourceForge
 as
  an
  external mirror and passes traffic through our download redirector
 flow
  (not direct to a mirror).
 
  The first two cases are things we can't control.
 
  In the third case, we can indeed redirect this traffic by referrer to
 a
  different landing page if one is provided. Maybe we want to have a
  openoffice.org page explaining that's a release-candidate and it's
  served
  only for testing purposes and its use on a daily basis it is not
  recommended.
 
  How does that sound?
 
 
  I'm pretty sure that these kind of downloaders do not care about
  disclaimers - less then 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Marcus (OOo)

Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini:

2014-04-03 13:09 GMT+02:00 Rob Weirrobw...@apache.org:


On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de  wrote:

Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:


2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:



   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:



On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
wrote:



On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)

marcus.m...@wtnet.de



wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:



2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:



Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):



Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):



Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:



Rob Weir wrote:



http://linux.softpedia.com/get/Office/Office-Suites/





   Apache-OpenOffice-253.shtml





  Or maybe a disclaimer in the voting thread email?






   Andrew's comments show clearly that these editors do not
care


to be
careful or factual, or even read those disclaimers,
unfortunately.

We can be successful only if we manage to block their
downloads.

   They






   link to our binaries hosted on SourceForge (which is fine). Just




thinking loud, but if it was possible (on the Sourceforge side)

to


deny
all download requests that do not come from the
openoffice.orgor

   the






   sourceforge.net domains, then the project would effectively be

in




control. The embargo could be lifted just after the release.




   For me this sounds like a great idea.



Maybe we should start with denying all download requests that
some

   from






   these bad websites.






@Roberto:
Can you tell us if this possible? If yes, is it much effort

for

you?


   Do you see a chance to get this implemented? I think it

could


help to
stop some bad websites to do bad things with our software.


   @Roberto:


Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this


thread
before.




   It would be great if you can tell us if it's possible to

exclude


some
domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if


that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked
from
downloading from Sourceforge. Obviously needs to be extended in

the


   future.



   Remember, the next will happen with the AOO 4.1.0 RC. ;-)



*Of course*, this is just for the time frame as long as the new
version

   is



   not officially announced. As soon as the release is public, the
block



   will



   be removed.



@all:
I think this could help to limit the downloadability like we want

to

see
until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to

the


files, go to test them, see the links don't work, and then get

weird

errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?



   To be honest, I don't care about a few days were a special set of


domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us

as

best
as possible.


+1 This seems sufficient to me.





@Roberto:
Do you see a technical way to return a predefined error message when
the
release builds are already on Sourceforge but not yet officially
released
and published?



Our SiteOps team looked into this, here our findings:



Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (


computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge

as

an
external mirror and passes traffic through our download redirector

flow

(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to

a

different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's
served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?



I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)

So, either we disable the entire download for the specific timeframe or
at
least a text as substitute (like This release is not yet public.

Please

stay 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Roberto Galoppini
2014-04-03 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de:

 Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini:

  2014-04-03 13:09 GMT+02:00 Rob Weirrobw...@apache.org:

  On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de
  wrote:

 Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:

  2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

  Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:



Am 03/31/2014 11:56 PM, schrieb Kay Schenk:



 On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
 wrote:


 On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)

 marcus.m...@wtnet.de


  wrote:

Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:



 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de
 :


 Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


 Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


 Rob Weir wrote:


 http://linux.softpedia.com/get/Office/Office-Suites/



 Apache-OpenOffice-253.shtml





   Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do not
 care


 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their
 downloads.

They




 link to our binaries hosted on SourceForge (which is
 fine). Just



  thinking loud, but if it was possible (on the Sourceforge side)

 to


 deny
 all download requests that do not come from the
 openoffice.orgor

the




 sourceforge.net domains, then the project would
 effectively be

 in



  control. The embargo could be lifted just after the release.




For me this sounds like a great idea.



 Maybe we should start with denying all download requests that
 some

from




 these bad websites.




  @Roberto:
 Can you tell us if this possible? If yes, is it much effort

 for

 you?


Do you see a chance to get this implemented? I think it

 could


 help to
 stop some bad websites to do bad things with our software.


@Roberto:


 Maybe you haven't seen this up to now.


Thanks for heads up Marcus, sorry for not having noticed
 this


 thread
 before.




It would be great if you can tell us if it's possible to

 exclude


 some
 domains / IP addresses from downloading our software?


I need the domain list and I'll check out with our SiteOps
 if


 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked
 from
 downloading from Sourceforge. Obviously needs to be extended in

 the


future.



Remember, the next will happen with the AOO 4.1.0 RC. ;-)



 *Of course*, this is just for the time frame as long as the new
 version

is



not officially announced. As soon as the release is public, the
 block



will



be removed.



 @all:
 I think this could help to limit the downloadability like we want

 to

 see
 until the official release. What you think?


I don't know.  Won't this just cause confusion?  They point to

 the


 files, go to test them, see the links don't work, and then get

 weird

 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release
 is
 officially approved  or something like that?


 To be honest, I don't care about a few days were a special
 set of


 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us

 as

 best
 as possible.


 +1 This seems sufficient to me.



  @Roberto:
 Do you see a technical way to return a predefined error message when
 the
 release builds are already on Sourceforge but not yet officially
 released
 and published?


  Our SiteOps team looked into this, here our findings:


 Great :-)


One provider (chip.de) serves via Akamai CDN, one provider (


 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge

 as

 an
 external mirror and passes traffic through our download redirector

 flow

 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to

 a

 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's
 served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Marcus (OOo)

Am 04/03/2014 01:09 PM, schrieb Rob Weir:

On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)marcus.m...@wtnet.de  wrote:

Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:


2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:



   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:



On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
wrote:



On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de


wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:



2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:



Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):



Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):



Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:



Rob Weir wrote:



http://linux.softpedia.com/get/Office/Office-Suites/





   Apache-OpenOffice-253.shtml





  Or maybe a disclaimer in the voting thread email?






   Andrew's comments show clearly that these editors do not
care


to be
careful or factual, or even read those disclaimers,
unfortunately.

We can be successful only if we manage to block their
downloads.

   They






   link to our binaries hosted on SourceForge (which is fine). Just




thinking loud, but if it was possible (on the Sourceforge side) to


deny
all download requests that do not come from the
openoffice.orgor

   the






   sourceforge.net domains, then the project would effectively be in




control. The embargo could be lifted just after the release.




   For me this sounds like a great idea.



Maybe we should start with denying all download requests that
some

   from






   these bad websites.






@Roberto:
Can you tell us if this possible? If yes, is it much effort for
you?


   Do you see a chance to get this implemented? I think it could


help to
stop some bad websites to do bad things with our software.


   @Roberto:


Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this


thread
before.




   It would be great if you can tell us if it's possible to exclude


some
domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if


that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked
from
downloading from Sourceforge. Obviously needs to be extended in the

   future.



   Remember, the next will happen with the AOO 4.1.0 RC. ;-)



*Of course*, this is just for the time frame as long as the new
version

   is



   not officially announced. As soon as the release is public, the
block



   will



   be removed.



@all:
I think this could help to limit the downloadability like we want to
see
until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to the


files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?



   To be honest, I don't care about a few days were a special set of


domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us as
best
as possible.


+1 This seems sufficient to me.





@Roberto:
Do you see a technical way to return a predefined error message when
the
release builds are already on Sourceforge but not yet officially
released
and published?



Our SiteOps team looked into this, here our findings:



Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (


computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as
an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's
served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?



I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)

So, either we disable the entire download for the specific timeframe or
at
least a text as substitute (like This release is not yet public. Please
stay tuned and come back when it is announced.). But this text has then
to
be on Sourceforge in 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread 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 Schmidtjogischm...@gmail.com:


On 4/2/14 11:19 PM, Marcus (OOo) wrote:

Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:

2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

   2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:


On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
wrote:



On Mon, Mar 31, 2014 at 4:43 PM, Marcus
(OOo)marcus.m...@wtnet.de


wrote:

   Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:



Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):



Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):



Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:



Rob Weir wrote:



http://linux.softpedia.com/get/Office/Office-Suites/





   Apache-OpenOffice-253.shtml




  Or maybe a disclaimer in the voting thread email?






   Andrew's comments show clearly that these editors do not
care

to be
careful or factual, or even read those disclaimers,
unfortunately.

We can be successful only if we manage to block their
downloads.

   They





   link to our binaries hosted on SourceForge (which is fine). Just



thinking loud, but if it was possible (on the Sourceforge side)

to

deny
all download requests that do not come from the
openoffice.orgor

   the





   sourceforge.net domains, then the project would effectively be

in



control. The embargo could be lifted just after the release.



   For me this sounds like a great idea.


Maybe we should start with denying all download requests
that some

   from





   these bad websites.





@Roberto:
Can you tell us if this possible? If yes, is it much effort

for

you?


   Do you see a chance to get this implemented? I think it

could

help to
stop some bad websites to do bad things with our software.


   @Roberto:

Maybe you haven't seen this up to now.


   Thanks for heads up Marcus, sorry for not having noticed this

thread
before.




   It would be great if you can tell us if it's possible to

exclude

some
domains / IP addresses from downloading our software?


   I need the domain list and I'll check out with our SiteOps if

that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked
from
downloading from Sourceforge. Obviously needs to be extended in

the


   future.


   Remember, the next will happen with the AOO 4.1.0 RC. ;-)


*Of course*, this is just for the time frame as long as the new
version

   is


   not officially announced. As soon as the release is public, the
block


   will


   be removed.


@all:
I think this could help to limit the downloadability like we
want to
see
until the official release. What you think?


   I don't know.  Won't this just cause confusion?  They point to
the

files, go to test them, see the links don't work, and then get

weird

errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?



   To be honest, I don't care about a few days were a special set of

domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us

as

best
as possible.


+1 This seems sufficient to me.





@Roberto:
Do you see a technical way to return a predefined error message
when the
release builds are already on Sourceforge but not yet officially
released
and published?



Our SiteOps team looked into this, here our findings:



Great :-)


   One provider (chip.de) serves via Akamai CDN, one provider (

computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge

as

an
external mirror and passes traffic through our download redirector

flow

(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to

a

different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's
served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?



I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)

So, either we disable the entire download for the specific timeframe
or at
least a text as substitute (like This release is not yet public.

Please

stay tuned and come 

Re: Anything we can do about premature redistribution?

2014-04-03 Thread Roberto Galoppini
2014-04-03 21:44 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de:

 Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt:

  On 4/3/14 12:09 PM, Roberto Galoppini wrote:

 2014-04-03 8:52 GMT+02:00 Jürgen Schmidtjogischm...@gmail.com:

  On 4/2/14 11:19 PM, Marcus (OOo) wrote:

 Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:

 2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

  Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/31/2014 11:56 PM, schrieb Kay Schenk:


 On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org
 wrote:


 On Mon, Mar 31, 2014 at 4:43 PM, Marcus
 (OOo)marcus.m...@wtnet.de

  wrote:

Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


 2014-03-28 21:24 GMT+01:00 Marcus (OOo)
 marcus.m...@wtnet.de:


 Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


 Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


 Rob Weir wrote:


 http://linux.softpedia.com/get/Office/Office-Suites/



 Apache-OpenOffice-253.shtml




   Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do
 not
 care

 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their
 downloads.

They



 link to our binaries hosted on SourceForge (which is
 fine). Just


  thinking loud, but if it was possible (on the Sourceforge side)

 to

 deny
 all download requests that do not come from the
 openoffice.orgor

the



 sourceforge.net domains, then the project would
 effectively be

 in


  control. The embargo could be lifted just after the release.



For me this sounds like a great idea.


 Maybe we should start with denying all download requests
 that some

from



 these bad websites.



  @Roberto:
 Can you tell us if this possible? If yes, is it much effort

 for

 you?


Do you see a chance to get this implemented? I think it

 could

 help to
 stop some bad websites to do bad things with our software.


@Roberto:

 Maybe you haven't seen this up to now.


Thanks for heads up Marcus, sorry for not having noticed
 this

 thread
 before.




It would be great if you can tell us if it's possible to

 exclude

 some
 domains / IP addresses from downloading our software?


I need the domain list and I'll check out with our SiteOps
 if

 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked
 from
 downloading from Sourceforge. Obviously needs to be extended in

 the


future.


Remember, the next will happen with the AOO 4.1.0 RC. ;-)


 *Of course*, this is just for the time frame as long as the new
 version

is


not officially announced. As soon as the release is public,
 the
 block


will


be removed.


 @all:
 I think this could help to limit the downloadability like we
 want to
 see
 until the official release. What you think?


I don't know.  Won't this just cause confusion?  They point
 to
 the

 files, go to test them, see the links don't work, and then get

 weird

 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release
 is
 officially approved  or something like that?


 To be honest, I don't care about a few days were a special
 set of

 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us

 as

 best
 as possible.


 +1 This seems sufficient to me.



  @Roberto:
 Do you see a technical way to return a predefined error message
 when the
 release builds are already on Sourceforge but not yet officially
 released
 and published?


  Our SiteOps team looked into this, here our findings:


 Great :-)


One provider (chip.de) serves via Akamai CDN, one provider (

 computerbase.de)
 serves via their own FTP server, and softpedia.com lists
 SourceForge

 as

 an
 external mirror and passes traffic through our download redirector

 flow

 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer
 to

 a

 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's
 served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever when located 

Re: Anything we can do about premature redistribution?

2014-04-02 Thread Roberto Galoppini
2014-04-01 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de:

 Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

  On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org  wrote:

  On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de
 wrote:

 Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

  2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:

  Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):

  Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):

  Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:

  Rob Weir wrote:

  http://linux.softpedia.com/get/Office/Office-Suites/


 Apache-OpenOffice-253.shtml



Or maybe a disclaimer in the voting thread email?




 Andrew's comments show clearly that these editors do not care to be
 careful or factual, or even read those disclaimers, unfortunately.

 We can be successful only if we manage to block their downloads.

 They

 link to our binaries hosted on SourceForge (which is fine). Just
 thinking loud, but if it was possible (on the Sourceforge side) to
 deny
 all download requests that do not come from the openoffice.org or

 the

 sourceforge.net domains, then the project would effectively be in
 control. The embargo could be lifted just after the release.


 For me this sounds like a great idea.

 Maybe we should start with denying all download requests that some

 from

 these bad websites.

 @Roberto:
 Can you tell us if this possible? If yes, is it much effort for you?


 Do you see a chance to get this implemented? I think it could help to
 stop some bad websites to do bad things with our software.


 @Roberto:
 Maybe you haven't seen this up to now.


 Thanks for heads up Marcus, sorry for not having noticed this thread
 before.




 It would be great if you can tell us if it's possible to exclude some
 domains / IP addresses from downloading our software?


 I need the domain list and I'll check out with our SiteOps if that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked from
 downloading from Sourceforge. Obviously needs to be extended in the

 future.

 Remember, the next will happen with the AOO 4.1.0 RC. ;-)

 *Of course*, this is just for the time frame as long as the new version

 is

 not officially announced. As soon as the release is public, the block

 will

 be removed.

 @all:
 I think this could help to limit the downloadability like we want to see
 until the official release. What you think?


 I don't know.  Won't this just cause confusion?  They point to the
 files, go to test them, see the links don't work, and then get weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?


 To be honest, I don't care about a few days were a special set of domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us as best
 as possible.


  +1 This seems sufficient to me.


 @Roberto:
 Do you see a technical way to return a predefined error message when the
 release builds are already on Sourceforge but not yet officially released
 and published?


Our SiteOps team looked into this, here our findings:

One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?

Roberto



 Thanks


 Marcus



  Then we can exclude requester that we don't want (e.g., malware
 distributors).

 Also in time frames with Beta or RC releases it can help us to steer

 who

 is able and when it is possible to download OpenOffice like we want to
 see
 until the real release date is reached.




  Thanks

 Marcus



Sure, sites could still copy all binaries being voted upon and
 offer


 them locally, but this would require a more significant effort. on
 their
 side.


 And more HDD space and more own bandwith - which is also not what

 they

 want.

 Marcus




Re: Anything we can do about premature redistribution?

2014-04-02 Thread Kay Schenk
On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini 
roberto.galopp...@gmail.com wrote:

 2014-04-01 21:30 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de:

  Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
 
   On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org  wrote:
 
   On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de
  wrote:
 
  Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
 
   2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:
 
   Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
 
   Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
 
   Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
 
   Rob Weir wrote:
 
   http://linux.softpedia.com/get/Office/Office-Suites/
 
 
  Apache-OpenOffice-253.shtml
 
 
 
 Or maybe a disclaimer in the voting thread email?
 
 
 
 
  Andrew's comments show clearly that these editors do not care to
 be
  careful or factual, or even read those disclaimers,
 unfortunately.
 
  We can be successful only if we manage to block their downloads.
 
  They
 
  link to our binaries hosted on SourceForge (which is fine). Just
  thinking loud, but if it was possible (on the Sourceforge side)
 to
  deny
  all download requests that do not come from the openoffice.orgor
 
  the
 
  sourceforge.net domains, then the project would effectively be in
  control. The embargo could be lifted just after the release.
 
 
  For me this sounds like a great idea.
 
  Maybe we should start with denying all download requests that some
 
  from
 
  these bad websites.
 
  @Roberto:
  Can you tell us if this possible? If yes, is it much effort for
 you?
 
 
  Do you see a chance to get this implemented? I think it could help
 to
  stop some bad websites to do bad things with our software.
 
 
  @Roberto:
  Maybe you haven't seen this up to now.
 
 
  Thanks for heads up Marcus, sorry for not having noticed this thread
  before.
 
 
 
 
  It would be great if you can tell us if it's possible to exclude
 some
  domains / IP addresses from downloading our software?
 
 
  I need the domain list and I'll check out with our SiteOps if that's
  doable. Feel free to send me a list with a direct message.
 
 
 
  - chip.de
  - computerbase.de
  - softpedia.com
 
  This would be the domains from this thread that could be blocked from
  downloading from Sourceforge. Obviously needs to be extended in the
 
  future.
 
  Remember, the next will happen with the AOO 4.1.0 RC. ;-)
 
  *Of course*, this is just for the time frame as long as the new
 version
 
  is
 
  not officially announced. As soon as the release is public, the block
 
  will
 
  be removed.
 
  @all:
  I think this could help to limit the downloadability like we want to
 see
  until the official release. What you think?
 
 
  I don't know.  Won't this just cause confusion?  They point to the
  files, go to test them, see the links don't work, and then get weird
  errors and spend an hour trying to debug it.  We don't want to
  needlessly annoy them, since their only fault is enthusiasm.   Is
  there a way we can give a useful error message in this case like,
  This version of Apache OpenOffice has not yet been officially
  released.  Links to these files are disallowed until the release is
  officially approved  or something like that?
 
 
  To be honest, I don't care about a few days were a special set of domains
  were not able to access for a few days. For me they are a bit too
  enthusiastic. And as you said in a previous post it's to protect us as
 best
  as possible.
 
 
   +1 This seems sufficient to me.
 
 
  @Roberto:
  Do you see a technical way to return a predefined error message when the
  release builds are already on Sourceforge but not yet officially released
  and published?
 

 Our SiteOps team looked into this, here our findings:

 One provider (chip.de) serves via Akamai CDN, one provider (
 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge as an
 external mirror and passes traffic through our download redirector flow
 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to a
 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?

 Roberto


Roberto -- thanks for all this investigation.


Should we assume that this caution should only be applied to:

 http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/

assuming this area would always be used for betas?




 
  Thanks
 
 
  Marcus
 
 
 
   Then we can exclude requester that we don't want (e.g., malware
  distributors).
 
  Also in time frames with Beta or RC releases it can help us to steer
 
  who
 
  is able and when it is possible to download OpenOffice like we want to
  see
  until the real release date is 

Re: Anything we can do about premature redistribution?

2014-04-02 Thread Marcus (OOo)

Am 04/02/2014 06:52 PM, schrieb Kay Schenk:

On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini
roberto.galopp...@gmail.com  wrote:


2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

  On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org   wrote:


  On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de

wrote:


Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

  2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


  Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


  Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


  Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


  Rob Weir wrote:


  http://linux.softpedia.com/get/Office/Office-Suites/





Apache-OpenOffice-253.shtml



Or maybe a disclaimer in the voting thread email?







Andrew's comments show clearly that these editors do not care to

be

careful or factual, or even read those disclaimers,

unfortunately.


We can be successful only if we manage to block their downloads.


They



link to our binaries hosted on SourceForge (which is fine). Just

thinking loud, but if it was possible (on the Sourceforge side)

to

deny
all download requests that do not come from the openoffice.orgor


the



sourceforge.net domains, then the project would effectively be in

control. The embargo could be lifted just after the release.



For me this sounds like a great idea.

Maybe we should start with denying all download requests that some


from



these bad websites.


@Roberto:
Can you tell us if this possible? If yes, is it much effort for

you?




Do you see a chance to get this implemented? I think it could help

to

stop some bad websites to do bad things with our software.



@Roberto:
Maybe you haven't seen this up to now.



Thanks for heads up Marcus, sorry for not having noticed this thread
before.





It would be great if you can tell us if it's possible to exclude

some

domains / IP addresses from downloading our software?



I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the


future.


Remember, the next will happen with the AOO 4.1.0 RC. ;-)

*Of course*, this is just for the time frame as long as the new

version



is


not officially announced. As soon as the release is public, the block


will


be removed.

@all:
I think this could help to limit the downloadability like we want to

see

until the official release. What you think?



I don't know.  Won't this just cause confusion?  They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?




To be honest, I don't care about a few days were a special set of domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us as

best

as possible.


  +1 This seems sufficient to me.




@Roberto:
Do you see a technical way to return a predefined error message when the
release builds are already on Sourceforge but not yet officially released
and published?



Our SiteOps team looked into this, here our findings:

One provider (chip.de) serves via Akamai CDN, one provider (
computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?

Roberto



Roberto -- thanks for all this investigation.


Should we assume that this caution should only be applied to:

  http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/

assuming this area would always be used for betas?


Without other opinions I would assume the same. For Beta or any other 
pre-final releases this would help.


However, the problem remains when it comes to a final release that is 
located one subdir up in .../files/:


We want to protect the release builds until we have really announced it 
officially.


So, IMHO it has to be a more generic solution like the staging-bit or 
a substitute text (see my other mail to 

Re: Anything we can do about premature redistribution?

2014-04-02 Thread Marcus (OOo)

Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

  On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org   wrote:


  On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de

wrote:


Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

  2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


  Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


  Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


  Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


  Rob Weir wrote:


  http://linux.softpedia.com/get/Office/Office-Suites/





Apache-OpenOffice-253.shtml



Or maybe a disclaimer in the voting thread email?







Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads.


They



link to our binaries hosted on SourceForge (which is fine). Just

thinking loud, but if it was possible (on the Sourceforge side) to
deny
all download requests that do not come from the openoffice.org or


the



sourceforge.net domains, then the project would effectively be in

control. The embargo could be lifted just after the release.



For me this sounds like a great idea.

Maybe we should start with denying all download requests that some


from



these bad websites.


@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?



Do you see a chance to get this implemented? I think it could help to
stop some bad websites to do bad things with our software.



@Roberto:
Maybe you haven't seen this up to now.



Thanks for heads up Marcus, sorry for not having noticed this thread
before.





It would be great if you can tell us if it's possible to exclude some
domains / IP addresses from downloading our software?



I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the


future.


Remember, the next will happen with the AOO 4.1.0 RC. ;-)

*Of course*, this is just for the time frame as long as the new version


is


not officially announced. As soon as the release is public, the block


will


be removed.

@all:
I think this could help to limit the downloadability like we want to see
until the official release. What you think?



I don't know.  Won't this just cause confusion?  They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?




To be honest, I don't care about a few days were a special set of domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us as best
as possible.


  +1 This seems sufficient to me.




@Roberto:
Do you see a technical way to return a predefined error message when the
release builds are already on Sourceforge but not yet officially released
and published?



Our SiteOps team looked into this, here our findings:


Great :-)


One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?


I'm pretty sure that these kind of downloaders do not care about 
disclaimers - less then ever when located somewhere else. ;-)


So, either we disable the entire download for the specific timeframe or 
at least a text as substitute (like This release is not yet public. 
Please stay tuned and come back when it is announced.). But this text 
has then to be on Sourceforge in the same location.


I'm wondering if the staging bit can help as best solution. I would 
expect that the new location is not public *and* not known *and* not 
useable/functional for the normal non-admin user *until* we remove the 
bit. Am I right?


Thanks

Marcus




  Then we can exclude requester that we don't want (e.g., malware

distributors).

Also in time frames with 

Re: Anything we can do about premature redistribution?

2014-04-02 Thread Roberto Galoppini
2014-04-02 21:15 GMT+02:00 Marcus (OOo) marcus.m...@wtnet.de:

 Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

  2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:

  Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

   On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org   wrote:


   On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de

 wrote:

  Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

   2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


   Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


   Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


   Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


   Rob Weir wrote:


   http://linux.softpedia.com/get/Office/Office-Suites/



  Apache-OpenOffice-253.shtml



 Or maybe a disclaimer in the voting thread email?




  Andrew's comments show clearly that these editors do not care
 to be
 careful or factual, or even read those disclaimers,
 unfortunately.

 We can be successful only if we manage to block their downloads.

  They


  link to our binaries hosted on SourceForge (which is fine). Just

 thinking loud, but if it was possible (on the Sourceforge side) to
 deny
 all download requests that do not come from the openoffice.orgor

  the


  sourceforge.net domains, then the project would effectively be in

 control. The embargo could be lifted just after the release.


  For me this sounds like a great idea.

 Maybe we should start with denying all download requests that some

  from


  these bad websites.


 @Roberto:
 Can you tell us if this possible? If yes, is it much effort for
 you?


  Do you see a chance to get this implemented? I think it could
 help to
 stop some bad websites to do bad things with our software.


  @Roberto:
 Maybe you haven't seen this up to now.


  Thanks for heads up Marcus, sorry for not having noticed this
 thread
 before.




  It would be great if you can tell us if it's possible to exclude
 some
 domains / IP addresses from downloading our software?


  I need the domain list and I'll check out with our SiteOps if
 that's
 doable. Feel free to send me a list with a direct message.



 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked from
 downloading from Sourceforge. Obviously needs to be extended in the

  future.

  Remember, the next will happen with the AOO 4.1.0 RC. ;-)

 *Of course*, this is just for the time frame as long as the new
 version

  is

  not officially announced. As soon as the release is public, the block

  will

  be removed.

 @all:
 I think this could help to limit the downloadability like we want to
 see
 until the official release. What you think?


  I don't know.  Won't this just cause confusion?  They point to the
 files, go to test them, see the links don't work, and then get weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?


  To be honest, I don't care about a few days were a special set of
 domains
 were not able to access for a few days. For me they are a bit too
 enthusiastic. And as you said in a previous post it's to protect us as
 best
 as possible.


   +1 This seems sufficient to me.



 @Roberto:
 Do you see a technical way to return a predefined error message when the
 release builds are already on Sourceforge but not yet officially released
 and published?


 Our SiteOps team looked into this, here our findings:


 Great :-)


  One provider (chip.de) serves via Akamai CDN, one provider (
 computerbase.de)
 serves via their own FTP server, and softpedia.com lists SourceForge as
 an
 external mirror and passes traffic through our download redirector flow
 (not direct to a mirror).

 The first two cases are things we can't control.

 In the third case, we can indeed redirect this traffic by referrer to a
 different landing page if one is provided. Maybe we want to have a
 openoffice.org page explaining that's a release-candidate and it's served
 only for testing purposes and its use on a daily basis it is not
 recommended.

 How does that sound?


 I'm pretty sure that these kind of downloaders do not care about
 disclaimers - less then ever when located somewhere else. ;-)

 So, either we disable the entire download for the specific timeframe or at
 least a text as substitute (like This release is not yet public. Please
 stay tuned and come back when it is announced.). But this text has then to
 be on Sourceforge in the same location.


Yes, that's doable in the way Kay described. And yes, we would add the text
and disable downloads.



 I'm wondering if the staging bit can help as best solution. I would
 expect that the new location 

Re: Anything we can do about premature redistribution?

2014-04-02 Thread Marcus (OOo)

Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:

2014-04-02 21:15 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:

  2014-04-01 21:30 GMT+02:00 Marcus (OOo)marcus.m...@wtnet.de:


  Am 03/31/2014 11:56 PM, schrieb Kay Schenk:


   On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.orgwrote:



   On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de


wrote:

  Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


   2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:



   Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):



   Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):



   Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:



   Rob Weir wrote:



   http://linux.softpedia.com/get/Office/Office-Suites/





  Apache-OpenOffice-253.shtml




 Or maybe a disclaimer in the voting thread email?






  Andrew's comments show clearly that these editors do not care

to be
careful or factual, or even read those disclaimers,
unfortunately.

We can be successful only if we manage to block their downloads.

  They





  link to our binaries hosted on SourceForge (which is fine). Just



thinking loud, but if it was possible (on the Sourceforge side) to

deny
all download requests that do not come from the openoffice.orgor

  the





  sourceforge.net domains, then the project would effectively be in



control. The embargo could be lifted just after the release.



  For me this sounds like a great idea.


Maybe we should start with denying all download requests that some

  from





  these bad websites.





@Roberto:
Can you tell us if this possible? If yes, is it much effort for
you?


  Do you see a chance to get this implemented? I think it could

help to
stop some bad websites to do bad things with our software.


  @Roberto:

Maybe you haven't seen this up to now.


  Thanks for heads up Marcus, sorry for not having noticed this

thread
before.




  It would be great if you can tell us if it's possible to exclude

some
domains / IP addresses from downloading our software?


  I need the domain list and I'll check out with our SiteOps if

that's
doable. Feel free to send me a list with a direct message.




- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the

  future.


  Remember, the next will happen with the AOO 4.1.0 RC. ;-)


*Of course*, this is just for the time frame as long as the new
version

  is


  not officially announced. As soon as the release is public, the block


  will


  be removed.


@all:
I think this could help to limit the downloadability like we want to
see
until the official release. What you think?


  I don't know.  Won't this just cause confusion?  They point to the

files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?



  To be honest, I don't care about a few days were a special set of

domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us as
best
as possible.


   +1 This seems sufficient to me.





@Roberto:
Do you see a technical way to return a predefined error message when the
release builds are already on Sourceforge but not yet officially released
and published?



Our SiteOps team looked into this, here our findings:



Great :-)


  One provider (chip.de) serves via Akamai CDN, one provider (

computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as
an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).

The first two cases are things we can't control.

In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.

How does that sound?



I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)

So, either we disable the entire download for the specific timeframe or at
least a text as substitute (like This release is not yet public. Please
stay tuned and come back when it is announced.). But this text has then to
be on Sourceforge in the same location.



Yes, that's doable in the way Kay described. And yes, we would add the text
and disable downloads.


Just to be sure, is this limited to a special subdir like 

Re: Anything we can do about premature redistribution?

2014-04-01 Thread Marcus (OOo)

Am 03/31/2014 11:56 PM, schrieb Kay Schenk:

On Mon, Mar 31, 2014 at 1:48 PM, Rob Weirrobw...@apache.org  wrote:


On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)marcus.m...@wtnet.de
wrote:

Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/


Apache-OpenOffice-253.shtml



   Or maybe a disclaimer in the voting thread email?





Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads.

They

link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to
deny
all download requests that do not come from the openoffice.org or

the

sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.



For me this sounds like a great idea.

Maybe we should start with denying all download requests that some

from

these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?



Do you see a chance to get this implemented? I think it could help to
stop some bad websites to do bad things with our software.



@Roberto:
Maybe you haven't seen this up to now.



Thanks for heads up Marcus, sorry for not having noticed this thread
before.





It would be great if you can tell us if it's possible to exclude some
domains / IP addresses from downloading our software?



I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.



- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the

future.

Remember, the next will happen with the AOO 4.1.0 RC. ;-)

*Of course*, this is just for the time frame as long as the new version

is

not officially announced. As soon as the release is public, the block

will

be removed.

@all:
I think this could help to limit the downloadability like we want to see
until the official release. What you think?



I don't know.  Won't this just cause confusion?  They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?


To be honest, I don't care about a few days were a special set of 
domains were not able to access for a few days. For me they are a bit 
too enthusiastic. And as you said in a previous post it's to protect us 
as best as possible.



+1 This seems sufficient to me.


@Roberto:
Do you see a technical way to return a predefined error message when the 
release builds are already on Sourceforge but not yet officially 
released and published?


Thanks

Marcus




Then we can exclude requester that we don't want (e.g., malware
distributors).

Also in time frames with Beta or RC releases it can help us to steer

who

is able and when it is possible to download OpenOffice like we want to
see
until the real release date is reached.





Thanks

Marcus



   Sure, sites could still copy all binaries being voted upon and offer


them locally, but this would require a more significant effort. on
their
side.



And more HDD space and more own bandwith - which is also not what

they

want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-04-01 Thread Jürgen Lange

+1 I like this way

Am 31.03.2014 22:48, schrieb Rob Weir:

On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote:

Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:


2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml



   Or maybe a disclaimer in the voting thread email?



Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to
deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.


For me this sounds like a great idea.

Maybe we should start with denying all download requests that some from
these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?


Do you see a chance to get this implemented? I think it could help to
stop some bad websites to do bad things with our software.


@Roberto:
Maybe you haven't seen this up to now.


Thanks for heads up Marcus, sorry for not having noticed this thread
before.




It would be great if you can tell us if it's possible to exclude some
domains / IP addresses from downloading our software?


I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.


- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the future.
Remember, the next will happen with the AOO 4.1.0 RC. ;-)

*Of course*, this is just for the time frame as long as the new version is
not officially announced. As soon as the release is public, the block will
be removed.

@all:
I think this could help to limit the downloadability like we want to see
until the official release. What you think?


I don't know.  Won't this just cause confusion?  They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?

-Rob


Marcus





Then we can exclude requester that we don't want (e.g., malware
distributors).

Also in time frames with Beta or RC releases it can help us to steer who
is able and when it is possible to download OpenOffice like we want to
see
until the real release date is reached.




Thanks

Marcus



   Sure, sites could still copy all binaries being voted upon and offer

them locally, but this would require a more significant effort. on
their
side.


And more HDD space and more own bandwith - which is also not what they
want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Anything we can do about premature redistribution?

2014-03-31 Thread Marcus (OOo)

Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:


Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):


Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml



  Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.



For me this sounds like a great idea.

Maybe we should start with denying all download requests that some from
these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?



Do you see a chance to get this implemented? I think it could help to
stop some bad websites to do bad things with our software.



@Roberto:
Maybe you haven't seen this up to now.



Thanks for heads up Marcus, sorry for not having noticed this thread before.





It would be great if you can tell us if it's possible to exclude some
domains / IP addresses from downloading our software?



I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.


- chip.de
- computerbase.de
- softpedia.com

This would be the domains from this thread that could be blocked from 
downloading from Sourceforge. Obviously needs to be extended in the 
future. Remember, the next will happen with the AOO 4.1.0 RC. ;-)


*Of course*, this is just for the time frame as long as the new version 
is not officially announced. As soon as the release is public, the block 
will be removed.


@all:
I think this could help to limit the downloadability like we want to see 
until the official release. What you think?


Marcus




Then we can exclude requester that we don't want (e.g., malware
distributors).

Also in time frames with Beta or RC releases it can help us to steer who
is able and when it is possible to download OpenOffice like we want to see
until the real release date is reached.




Thanks

Marcus



  Sure, sites could still copy all binaries being voted upon and offer

them locally, but this would require a more significant effort. on their
side.



And more HDD space and more own bandwith - which is also not what they
want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-31 Thread Rob Weir
On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote:
 Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:

 2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:

 Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):

 Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):

 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:

 Rob Weir wrote:

 http://linux.softpedia.com/get/Office/Office-Suites/

 Apache-OpenOffice-253.shtml



   Or maybe a disclaimer in the voting thread email?



 Andrew's comments show clearly that these editors do not care to be
 careful or factual, or even read those disclaimers, unfortunately.

 We can be successful only if we manage to block their downloads. They
 link to our binaries hosted on SourceForge (which is fine). Just
 thinking loud, but if it was possible (on the Sourceforge side) to
 deny
 all download requests that do not come from the openoffice.org or the
 sourceforge.net domains, then the project would effectively be in
 control. The embargo could be lifted just after the release.


 For me this sounds like a great idea.

 Maybe we should start with denying all download requests that some from
 these bad websites.

 @Roberto:
 Can you tell us if this possible? If yes, is it much effort for you?


 Do you see a chance to get this implemented? I think it could help to
 stop some bad websites to do bad things with our software.


 @Roberto:
 Maybe you haven't seen this up to now.


 Thanks for heads up Marcus, sorry for not having noticed this thread
 before.




 It would be great if you can tell us if it's possible to exclude some
 domains / IP addresses from downloading our software?


 I need the domain list and I'll check out with our SiteOps if that's
 doable. Feel free to send me a list with a direct message.


 - chip.de
 - computerbase.de
 - softpedia.com

 This would be the domains from this thread that could be blocked from
 downloading from Sourceforge. Obviously needs to be extended in the future.
 Remember, the next will happen with the AOO 4.1.0 RC. ;-)

 *Of course*, this is just for the time frame as long as the new version is
 not officially announced. As soon as the release is public, the block will
 be removed.

 @all:
 I think this could help to limit the downloadability like we want to see
 until the official release. What you think?


I don't know.  Won't this just cause confusion?  They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it.  We don't want to
needlessly annoy them, since their only fault is enthusiasm.   Is
there a way we can give a useful error message in this case like,
This version of Apache OpenOffice has not yet been officially
released.  Links to these files are disallowed until the release is
officially approved  or something like that?

-Rob

 Marcus




 Then we can exclude requester that we don't want (e.g., malware
 distributors).

 Also in time frames with Beta or RC releases it can help us to steer who
 is able and when it is possible to download OpenOffice like we want to
 see
 until the real release date is reached.



 Thanks

 Marcus



   Sure, sites could still copy all binaries being voted upon and offer

 them locally, but this would require a more significant effort. on
 their
 side.


 And more HDD space and more own bandwith - which is also not what they
 want.

 Marcus


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-31 Thread Kay Schenk
On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir robw...@apache.org wrote:

 On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) marcus.m...@wtnet.de
 wrote:
  Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
 
  2014-03-28 21:24 GMT+01:00 Marcus (OOo)marcus.m...@wtnet.de:
 
  Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
 
  Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
 
  Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
 
  Rob Weir wrote:
 
  http://linux.softpedia.com/get/Office/Office-Suites/
 
  Apache-OpenOffice-253.shtml
 
 
 
Or maybe a disclaimer in the voting thread email?
 
 
 
  Andrew's comments show clearly that these editors do not care to be
  careful or factual, or even read those disclaimers, unfortunately.
 
  We can be successful only if we manage to block their downloads.
 They
  link to our binaries hosted on SourceForge (which is fine). Just
  thinking loud, but if it was possible (on the Sourceforge side) to
  deny
  all download requests that do not come from the openoffice.org or
 the
  sourceforge.net domains, then the project would effectively be in
  control. The embargo could be lifted just after the release.
 
 
  For me this sounds like a great idea.
 
  Maybe we should start with denying all download requests that some
 from
  these bad websites.
 
  @Roberto:
  Can you tell us if this possible? If yes, is it much effort for you?
 
 
  Do you see a chance to get this implemented? I think it could help to
  stop some bad websites to do bad things with our software.
 
 
  @Roberto:
  Maybe you haven't seen this up to now.
 
 
  Thanks for heads up Marcus, sorry for not having noticed this thread
  before.
 
 
 
 
  It would be great if you can tell us if it's possible to exclude some
  domains / IP addresses from downloading our software?
 
 
  I need the domain list and I'll check out with our SiteOps if that's
  doable. Feel free to send me a list with a direct message.
 
 
  - chip.de
  - computerbase.de
  - softpedia.com
 
  This would be the domains from this thread that could be blocked from
  downloading from Sourceforge. Obviously needs to be extended in the
 future.
  Remember, the next will happen with the AOO 4.1.0 RC. ;-)
 
  *Of course*, this is just for the time frame as long as the new version
 is
  not officially announced. As soon as the release is public, the block
 will
  be removed.
 
  @all:
  I think this could help to limit the downloadability like we want to see
  until the official release. What you think?
 

 I don't know.  Won't this just cause confusion?  They point to the
 files, go to test them, see the links don't work, and then get weird
 errors and spend an hour trying to debug it.  We don't want to
 needlessly annoy them, since their only fault is enthusiasm.   Is
 there a way we can give a useful error message in this case like,
 This version of Apache OpenOffice has not yet been officially
 released.  Links to these files are disallowed until the release is
 officially approved  or something like that?

 -Rob


+1 This seems sufficient to me.



  Marcus
 
 
 
 
  Then we can exclude requester that we don't want (e.g., malware
  distributors).
 
  Also in time frames with Beta or RC releases it can help us to steer
 who
  is able and when it is possible to download OpenOffice like we want to
  see
  until the real release date is reached.
 
 
 
  Thanks
 
  Marcus
 
 
 
Sure, sites could still copy all binaries being voted upon and offer
 
  them locally, but this would require a more significant effort. on
  their
  side.
 
 
  And more HDD space and more own bandwith - which is also not what
 they
  want.
 
  Marcus
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




-- 
-
MzK

Cats do not have to be shown how to have a good time,
 for they are unfailing ingenious in that respect.
   -- James Mason


Re: Anything we can do about premature redistribution?

2014-03-28 Thread 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.

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?

2014-03-10 Thread Jürgen Schmidt
On 3/9/14 8:49 PM, Marcus (OOo) wrote:
 Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
 On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de 
 wrote:

 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:

 Rob Weir wrote:

 http://linux.softpedia.com/get/Office/Office-Suites/
 Apache-OpenOffice-253.shtml

   Or maybe a disclaimer in the voting thread email?


 Andrew's comments show clearly that these editors do not care to be
 careful or factual, or even read those disclaimers, unfortunately.

 We can be successful only if we manage to block their downloads. They
 link to our binaries hosted on SourceForge (which is fine). Just
 thinking loud, but if it was possible (on the Sourceforge side) to deny
 all download requests that do not come from the openoffice.org or the
 sourceforge.net domains, then the project would effectively be in
 control. The embargo could be lifted just after the release.


 I'm a bit confused by this statement. There are MANY sites the
 re-route to
 SourceForge for our downloads, and this is perfectly fine. The concern is
 for the  inadvertent download of not yet released Beta which is available
 from the following URL space which is not even SourceForge:

   http://ci.apache.org/projects/openoffice/milestones
 
 OK, for the Beta release in special this is true. It's not yet available
 on Sourceforge - at least I cannot see it.

it is there as well, hdu started the synch when the bits where ready on
the Apache server for some further testing purposes (especially upload
performance). And of course to have them in place in time for today.

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?

2014-03-10 Thread Andre Fischer

On 10.03.2014 08:32, Jürgen Schmidt wrote:

On 3/9/14 8:49 PM, Marcus (OOo) wrote:

Am 03/09/2014 07:33 PM, schrieb Kay Schenk:

On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml

   Or maybe a disclaimer in the voting thread email?

Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.


I'm a bit confused by this statement. There are MANY sites the
re-route to
SourceForge for our downloads, and this is perfectly fine. The concern is
for the  inadvertent download of not yet released Beta which is available
from the following URL space which is not even SourceForge:

   http://ci.apache.org/projects/openoffice/milestones

OK, for the Beta release in special this is true. It's not yet available
on Sourceforge - at least I cannot see it.

it is there as well, hdu started the synch when the bits where ready on
the Apache server for some further testing purposes (especially upload
performance). And of course to have them in place in time for today.

It was probably a little bit early but independent where we upload the
bits they will be grabbed immediately. Which is not necessarily bad if
they would do their job a little bit better ;-) There was no official
release announcement.


Is it possible to upload to some kind of staging area on sourceforge 
that is not accessible to the public?  Keep the bits there until our 
vote has finished and them move them to the download area?


-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?

2014-03-10 Thread Marcus (OOo)

Am 03/10/2014 08:32 AM, schrieb Jürgen Schmidt:

On 3/9/14 8:49 PM, Marcus (OOo) wrote:

Am 03/09/2014 07:33 PM, schrieb Kay Schenk:

On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml

   Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.




I'm a bit confused by this statement. There are MANY sites the
re-route to
SourceForge for our downloads, and this is perfectly fine. The concern is
for the  inadvertent download of not yet released Beta which is available
from the following URL space which is not even SourceForge:

   http://ci.apache.org/projects/openoffice/milestones


OK, for the Beta release in special this is true. It's not yet available
on Sourceforge - at least I cannot see it.


it is there as well, hdu started the synch when the bits where ready on
the Apache server for some further testing purposes (especially upload
performance). And of course to have them in place in time for today.


I've expected this. But what scares me is that I cannot see anything 
about the Beta even when I'm logged-in as admin.


Marcus




It was probably a little bit early but independent where we upload the
bits they will be grabbed immediately. Which is not necessarily bad if
they would do their job a little bit better ;-) There was no official
release announcement.

Juergen




In general, they link to our binaries at Sourceforge.


Correct? So, I think the restriction would need to be from ci.apache.org,
not SourceForge.


For the Beta release this is true.

However, I don't know how long this makes sense.

Marcus




For me this sounds like a great idea.

Maybe we should start with denying all download requests that some from
these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?

   Sure, sites could still copy all binaries being voted upon and offer

them locally, but this would require a more significant effort. on
their
side.



And more HDD space and more own bandwith - which is also not what they
want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-10 Thread Marcus (OOo)

Am 03/10/2014 08:57 AM, schrieb Andre Fischer:

On 10.03.2014 08:32, Jürgen Schmidt wrote:

On 3/9/14 8:49 PM, Marcus (OOo) wrote:

Am 03/09/2014 07:33 PM, schrieb Kay Schenk:

On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml

Or maybe a disclaimer in the voting thread email?

Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to
deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.


I'm a bit confused by this statement. There are MANY sites the
re-route to
SourceForge for our downloads, and this is perfectly fine. The
concern is
for the inadvertent download of not yet released Beta which is
available
from the following URL space which is not even SourceForge:

http://ci.apache.org/projects/openoffice/milestones

OK, for the Beta release in special this is true. It's not yet available
on Sourceforge - at least I cannot see it.

it is there as well, hdu started the synch when the bits where ready on
the Apache server for some further testing purposes (especially upload
performance). And of course to have them in place in time for today.

It was probably a little bit early but independent where we upload the
bits they will be grabbed immediately. Which is not necessarily bad if
they would do their job a little bit better ;-) There was no official
release announcement.


Is it possible to upload to some kind of staging area on sourceforge
that is not accessible to the public? Keep the bits there until our vote
has finished and them move them to the download area?


Yes, you can create a new folder and give it a staging bit. Then you can 
use it (e.g., upload things into it) but it is not visible to the outside.


Marcus




In general, they link to our binaries at Sourceforge.


Correct? So, I think the restriction would need to be from
ci.apache.org,
not SourceForge.

For the Beta release this is true.

However, I don't know how long this makes sense.

Marcus




For me this sounds like a great idea.

Maybe we should start with denying all download requests that some
from
these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?

Sure, sites could still copy all binaries being voted upon and offer

them locally, but this would require a more significant effort. on
their
side.


And more HDD space and more own bandwith - which is also not what they
want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-09 Thread Marcus (OOo)

Am 03/08/2014 12:29 AM, schrieb Vladislav Stevanovic:

When somebody want to download beta version of AOO it will be good aproach
to show pop-up dialog with warnings that this is not stable version and it
only for testing. We can not stopped other to write what they write about
AOO but we can protect potential users with info dialog when they press
link for downloading beta version.


That will be done on the download webpage - when the Beta is actually 
available.


Marcus




2014-03-08 0:09 GMT+01:00 Andrea Pescettipesce...@apache.org:


Rob Weir wrote:


  http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml


Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They link
to our binaries hosted on SourceForge (which is fine). Just thinking loud,
but if it was possible (on the Sourceforge side) to deny all download
requests that do not come from the openoffice.org or the 
sourceforge.netdomains, then the project would effectively be in control. The 
embargo
could be lifted just after the release.

Sure, sites could still copy all binaries being voted upon and offer them
locally, but this would require a more significant effort. on their side.

Regards,
   Andrea.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-09 Thread Kay Schenk
On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo) marcus.m...@wtnet.de wrote:

 Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:

 Rob Weir wrote:

 http://linux.softpedia.com/get/Office/Office-Suites/
 Apache-OpenOffice-253.shtml

  Or maybe a disclaimer in the voting thread email?


 Andrew's comments show clearly that these editors do not care to be
 careful or factual, or even read those disclaimers, unfortunately.

 We can be successful only if we manage to block their downloads. They
 link to our binaries hosted on SourceForge (which is fine). Just
 thinking loud, but if it was possible (on the Sourceforge side) to deny
 all download requests that do not come from the openoffice.org or the
 sourceforge.net domains, then the project would effectively be in
 control. The embargo could be lifted just after the release.


I'm a bit confused by this statement. There are MANY sites the re-route to
SourceForge for our downloads, and this is perfectly fine. The concern is
for the  inadvertent download of not yet released Beta which is available
from the following URL space which is not even SourceForge:

 http://ci.apache.org/projects/openoffice/milestones

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?

2014-03-09 Thread Andrea Pescetti

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?

2014-03-09 Thread Marcus (OOo)

Am 03/09/2014 07:33 PM, schrieb Kay Schenk:

On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de  wrote:


Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:


Rob Weir wrote:


http://linux.softpedia.com/get/Office/Office-Suites/

Apache-OpenOffice-253.shtml

  Or maybe a disclaimer in the voting thread email?




Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.

We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.




I'm a bit confused by this statement. There are MANY sites the re-route to
SourceForge for our downloads, and this is perfectly fine. The concern is
for the  inadvertent download of not yet released Beta which is available
from the following URL space which is not even SourceForge:

  http://ci.apache.org/projects/openoffice/milestones


OK, for the Beta release in special this is true. It's not yet available 
on Sourceforge - at least I cannot see it.


In general, they link to our binaries at Sourceforge.


Correct? So, I think the restriction would need to be from ci.apache.org,
not SourceForge.


For the Beta release this is true.

However, I don't know how long this makes sense.

Marcus




For me this sounds like a great idea.

Maybe we should start with denying all download requests that some from
these bad websites.

@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?

  Sure, sites could still copy all binaries being voted upon and offer

them locally, but this would require a more significant effort. on their
side.



And more HDD space and more own bandwith - which is also not what they
want.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-07 Thread Oliver-Rainer Wittmann

Hi,

On 07.03.2014 15:22, Rob Weir wrote:

Evidently we're already released, on some websites at least:

http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml

How much do we care about this?   The risk, I suppose, is on
Softpedia, that we could find a last-minute defect in the NOTICE or
other legal files, and they find themselves distributing a package
that is not correct.  But the practical risk there is small.

The greater risk is to users, that we find a last-minute fatal bug
that causes us to cancel the vote, but there are versions of the
Release Candidate still floating around.  That can hurt the AOO
reputation if that happened.

I'm not sure we can prevent this from happening, and still have an
open and transparent voting process.  But maybe there is something we
can do to discourage it?




softpedia is not the only one:
- http://www.chip.de/downloads/OpenOffice_14324674.html
- http://www.computerbase.de/downloads/office/


Best regards, Oliver.


-Rob

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-07 Thread Jürgen Schmidt
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?

2014-03-07 Thread Rob Weir
On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
 Hi,

 On 07.03.2014 15:22, Rob Weir wrote:
 Evidently we're already released, on some websites at least:

 http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml


 How much do we care about this?   The risk, I suppose, is on
 Softpedia, that we could find a last-minute defect in the NOTICE or
 other legal files, and they find themselves distributing a package
 that is not correct.  But the practical risk there is small.

 The greater risk is to users, that we find a last-minute fatal bug
 that causes us to cancel the vote, but there are versions of the
 Release Candidate still floating around.  That can hurt the AOO
 reputation if that happened.

 I'm not sure we can prevent this from happening, and still have an
 open and transparent voting process.  But maybe there is something we
 can do to discourage it?



 softpedia is not the only one:
 - http://www.chip.de/downloads/OpenOffice_14324674.html
 - http://www.computerbase.de/downloads/office/


 I think we can create a blog explaining the voting procedure and make
 clear where we are in the process and that it is the RC of the Beta only.


Or maybe a disclaimer in the voting thread email?   Next time we could
say something like:

Note:   All Apache releases require a vote of the PMC lasting at
least 72-hours.  We do not officially release until after that vote
has concluded.   We appreciate the enthusiasm of our users and 3rd
party distributors and their efforts to publicize our releases and
share them with a broader audience.  But we ask that you do not
publicize a release until the vote has concluded and the vote results
posted.  This is for the safety of the users.  It is always possible
for a last minute defect to be reported in a Release Candidate causing
us to cancel an in-progress vote.  in fact this has occurred before.
So be safe and wait for the release process to conclude.

I'm guessing that they hear about the RC from the email list, not the
wiki, so it might make sense to put a message like this in the vote
email.

-Rob


 But I don't know if this would really help to avoid confusion.

 Juergen



 Best regards, Oliver.

 -Rob

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-07 Thread Jürgen Schmidt
On 3/7/14 4:33 PM, Rob Weir wrote:
 On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
 Hi,

 On 07.03.2014 15:22, Rob Weir wrote:
 Evidently we're already released, on some websites at least:

 http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml


 How much do we care about this?   The risk, I suppose, is on
 Softpedia, that we could find a last-minute defect in the NOTICE or
 other legal files, and they find themselves distributing a package
 that is not correct.  But the practical risk there is small.

 The greater risk is to users, that we find a last-minute fatal bug
 that causes us to cancel the vote, but there are versions of the
 Release Candidate still floating around.  That can hurt the AOO
 reputation if that happened.

 I'm not sure we can prevent this from happening, and still have an
 open and transparent voting process.  But maybe there is something we
 can do to discourage it?



 softpedia is not the only one:
 - http://www.chip.de/downloads/OpenOffice_14324674.html
 - http://www.computerbase.de/downloads/office/


 I think we can create a blog explaining the voting procedure and make
 clear where we are in the process and that it is the RC of the Beta only.

 
 Or maybe a disclaimer in the voting thread email?   Next time we could
 say something like:
 
 Note:   All Apache releases require a vote of the PMC lasting at
 least 72-hours.  We do not officially release until after that vote
 has concluded.   We appreciate the enthusiasm of our users and 3rd
 party distributors and their efforts to publicize our releases and
 share them with a broader audience.  But we ask that you do not
 publicize a release until the vote has concluded and the vote results
 posted.  This is for the safety of the users.  It is always possible
 for a last minute defect to be reported in a Release Candidate causing
 us to cancel an in-progress vote.  in fact this has occurred before.
 So be safe and wait for the release process to conclude.
 
 I'm guessing that they hear about the RC from the email list, not the
 wiki, so it might make sense to put a message like this in the vote
 email.
 

+1, already marked and I will add it the next time. But for this time we
can put this text in a blog. Opinions?

Juergen


 -Rob
 
 
 But I don't know if this would really help to avoid confusion.

 Juergen



 Best regards, Oliver.

 -Rob

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-07 Thread Chuck Davis
A water-mark on new documents that directs people to find official
distributions on the web site?  The water-mark will be taken off when AOO
is out of beta and an official release is available.  At the least this
would require those who want to just redistribute know enough programming
to make it inconvenient for them.


On Fri, Mar 7, 2014 at 7:37 AM, Jürgen Schmidt jogischm...@gmail.comwrote:

 On 3/7/14 4:33 PM, Rob Weir wrote:
  On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt jogischm...@gmail.com
 wrote:
  On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
  Hi,
 
  On 07.03.2014 15:22, Rob Weir wrote:
  Evidently we're already released, on some websites at least:
 
 
 http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
 
 
  How much do we care about this?   The risk, I suppose, is on
  Softpedia, that we could find a last-minute defect in the NOTICE or
  other legal files, and they find themselves distributing a package
  that is not correct.  But the practical risk there is small.
 
  The greater risk is to users, that we find a last-minute fatal bug
  that causes us to cancel the vote, but there are versions of the
  Release Candidate still floating around.  That can hurt the AOO
  reputation if that happened.
 
  I'm not sure we can prevent this from happening, and still have an
  open and transparent voting process.  But maybe there is something we
  can do to discourage it?
 
 
 
  softpedia is not the only one:
  - http://www.chip.de/downloads/OpenOffice_14324674.html
  - http://www.computerbase.de/downloads/office/
 
 
  I think we can create a blog explaining the voting procedure and make
  clear where we are in the process and that it is the RC of the Beta
 only.
 
 
  Or maybe a disclaimer in the voting thread email?   Next time we could
  say something like:
 
  Note:   All Apache releases require a vote of the PMC lasting at
  least 72-hours.  We do not officially release until after that vote
  has concluded.   We appreciate the enthusiasm of our users and 3rd
  party distributors and their efforts to publicize our releases and
  share them with a broader audience.  But we ask that you do not
  publicize a release until the vote has concluded and the vote results
  posted.  This is for the safety of the users.  It is always possible
  for a last minute defect to be reported in a Release Candidate causing
  us to cancel an in-progress vote.  in fact this has occurred before.
  So be safe and wait for the release process to conclude.
 
  I'm guessing that they hear about the RC from the email list, not the
  wiki, so it might make sense to put a message like this in the vote
  email.
 

 +1, already marked and I will add it the next time. But for this time we
 can put this text in a blog. Opinions?

 Juergen


  -Rob
 
 
  But I don't know if this would really help to avoid confusion.
 
  Juergen
 
 
 
  Best regards, Oliver.
 
  -Rob
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org




Re: Anything we can do about premature redistribution?

2014-03-07 Thread Andrew Rist


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?

2014-03-07 Thread David Gerard
On 7 March 2014 22:30, Andrew Rist andrew.r...@oracle.com wrote:

It is derived from the IBM Lotus Symphony suite of applications...
- not correct


https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato
suggests this is not an unfair statement. Indeed, just rebasing on the
Symphony code was seriously considered.


Ever since the Oracle Corporation acquired the Sun Microsystems
company, work on Apache OpenOffice ceased, and various developers
who worked on the project decided to create a new project, named
LibreOffice. - neither correct nor pertinent


That's ridiculously wrong, to the point of warranting formal messages
of correction from both projects.


In general, I would suggest asking nicely as the very first approach,
when the beta is in fact approved and ready.


- d.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Anything we can do about premature redistribution?

2014-03-07 Thread 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.


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?

2014-03-07 Thread 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.
Regards,
Wlada


2014-03-08 0:09 GMT+01:00 Andrea Pescetti pesce...@apache.org:

 Rob Weir wrote:

  http://linux.softpedia.com/get/Office/Office-Suites/
 Apache-OpenOffice-253.shtml

 Or maybe a disclaimer in the voting thread email?


 Andrew's comments show clearly that these editors do not care to be
 careful or factual, or even read those disclaimers, unfortunately.

 We can be successful only if we manage to block their downloads. They link
 to our binaries hosted on SourceForge (which is fine). Just thinking loud,
 but if it was possible (on the Sourceforge side) to deny all download
 requests that do not come from the openoffice.org or the 
 sourceforge.netdomains, then the project would effectively be in control. The 
 embargo
 could be lifted just after the release.

 Sure, sites could still copy all binaries being voted upon and offer them
 locally, but this would require a more significant effort. on their side.

 Regards,
   Andrea.


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org