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 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.orgor
the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.
For me this sounds like a great idea.
Maybe we should start with denying all download requests that some
from
these bad websites.
@Roberto:
Can you tell us if this possible? If yes, is it much effort for
you?
Do you see a chance to get this implemented? I think it could help
to
stop some bad websites to do bad things with our software.
@Roberto:
Maybe you haven't seen this up to now.
Thanks for heads up Marcus, sorry for not having noticed this thread
before.
It would be great if you can tell us if it's possible to exclude
some
domains / IP addresses from downloading our software?
I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.
- chip.de
- computerbase.de
- softpedia.com
This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the
future.
Remember, the next will happen with the AOO 4.1.0 RC. ;-)
*Of course*, this is just for the time frame as long as the new
version
is
not officially announced. As soon as the release is public, the block
will
be removed.
@all:
I think this could help to limit the downloadability like we want to
see
until the official release. What you think?
I don't know. Won't this just cause confusion? They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it. We don't want to
needlessly annoy them, since their only fault is enthusiasm. Is
there a way we can give a useful error message in this case like,
"This version of Apache OpenOffice has not yet been officially
released. Links to these files are disallowed until the release is
officially approved" or something like that?
To be honest, I don't care about a few days were a special set of domains
were not able to access for a few days. For me they are a bit too
enthusiastic. And as you said in a previous post it's to protect us as
best
as possible.
+1 This seems sufficient to me.
@Roberto:
Do you see a technical way to return a predefined error message when the
release builds are already on Sourceforge but not yet officially released
and published?
Our SiteOps team looked into this, here our findings:
One provider (chip.de) serves via Akamai CDN, one provider (
computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).
The first two cases are things we can't control.
In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.
How does that sound?
Roberto
Roberto -- thanks for all this investigation.
Should we assume that this caution should only be applied to:
http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/
assuming this area would always be used for "betas"?
Without other opinions I would assume the same. For Beta or any other
pre-final releases this would help.
However, the problem remains when it comes to a final release that is
located one subdir up in ".../files/":
We want to protect the release builds until we have really announced it
officially.
So, IMHO it has to be a more generic solution like the "staging"-bit or
a substitute text (see my other mail to Roberto).
Marcus
Then we can exclude requester that we don't want (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
