Am 04/03/2014 11:12 PM, schrieb 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 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 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:
Great :-)
One provider (chip.de) serves via Akamai CDN, one provider (
computerbase.de)
serves via their own FTP server, and softpedia.com lists
SourceForge
as
an
external mirror and passes traffic through our download redirector
flow
(not direct to a mirror).
The first two cases are things we can't control.
In the third case, we can indeed redirect this traffic by referrer
to
a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's
served
only for testing purposes and its use on a daily basis it is not
recommended.
How does that sound?
I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)
So, either we disable the entire download for the specific timeframe
or at
least a text as substitute (like "This release is not yet public.
Please
stay tuned and come back when it is announced."). But this text has
then to
be on Sourceforge in the same location.
Yes, that's doable in the way Kay described. And yes, we would add the
text
and disable downloads.
Just to be sure, is this limited to a special subdir like
".../files/milestones/"? Or also, additionally for ".../files/"?
I'm wondering if the "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?
In past we extended the 'staging' period of time for weeks, this could
be
done again if necessary and it's definitely a more effective way to
share
Good to know. I thought you had extended the timeframe permanentelly.
;-)
files only with a selected audience (admins). Would that work, or you
want
to be able to share those files with a larger audience?
I don't think it's relevant to a wider audience.
We still speak about the timeframe between starting uploading to
Sourceforge and the official announcement. Within this timeframe it
should be possible for admins to test the download webpage with
scripting - to see if it will work - but there must not be no way to
download the builds from the public.
So, I would prefer to go with the "staging"-bit as:
- it is already available
- there is no confusion for the public
- it's easy to delete the bit to make the release public
- and (please don't get me wrong ;-) ) we can do it alone without the
help of you or someone else of Sourceforge.
What do others think about this?
sounds ok to me, we should make it to complicate. It wasn't a big thing
the last time and it shows the interest in AOO.
How do I set the staging bit?
Hi Jurgen,
Here you find more info: https://sourceforge.net/blog/staged-folders/
About extending the staging period I'll make sure it is set to a custom
value for AOO, usually it's 3 days.
custom value sounds good, the question is then how we can influence this
value.
When looking at the screenshots in the blog post, the "3" could be
exchanged with a inputfield or dropdown list to enter/choose an own value.
The "3 days" could be the default value.
I see that the staging bit can be removed at any time via folder
properties. Maybe a nice feature would be to simply allow a custom value
here or to extend the staging period if the vote fails or other problems
come up.
Maybe it's possible to extend the 3 days to, hm, more days for now and
have the customize feature in the future.
It's actually pre-set to 21 days, click on the 'i' and you'll read This
file is staged until Thu, 24 Apr 2014 13:04:32 GMT .
Again, if that's not enough I'll make sure to extend it further.
Ah, thanks for the hint, I've not seen this until now. :-)
For now the timeframe will be enough of course.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
