openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <roberto.galopp...@gmail.com>
Subject Re: Anything we can do about premature redistribution?
Date Wed, 02 Apr 2014 19:22:40 GMT
2014-04-02 21:15 GMT+02:00 Marcus (OOo) <marcus.mail@wtnet.de>:

> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>
>  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:
>>
>
> 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 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
files only with a selected audience (admins). Would that work, or you want
to be able to share those files with a larger audience?

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message