openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Anything we can do about premature redistribution?
Date Wed, 02 Apr 2014 19:15:20 GMT
Am 04/02/2014 06:52 PM, schrieb Kay Schenk:
> On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini<
> roberto.galoppini@gmail.com>  wrote:
>
>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<marcus.mail@wtnet.de>:
>>
>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>
>>>   On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<robweir@apache.org>   wrote:
>>>>
>>>>   On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<marcus.mail@wtnet.de>
>>>>> wrote:
>>>>>
>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>>   2014-03-28 21:24 GMT+01:00 Marcus (OOo)<marcus.mail@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message