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 Thu, 03 Apr 2014 19:39:36 GMT
Am 04/03/2014 01:09 PM, schrieb Rob Weir:
> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<marcus.mail@wtnet.de>  wrote:
>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>
>>> 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.
>>
>>
>> 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?
>>
>
> My original recommendation was to put a more prominent warning in the
> [VOTE] emails.  The problem is this:  if we are to have a public vote
> then the files we're voting on must also be public.  Whether this is
> on SourceForge or people.apache.org, it is publicly known that this is
> the 4.1 RC and some websites will download and copy onto their
> websites.   I don't think there is any technological means to prevent
> this.  We only have our ability to educate about the risks.

Sure, to put a note into the VOTE mail is nice but wouldn't help to 
avoid early downloads. I'm sure they will just smile and download 
anyway. ;-)

OK, maybe I've misinterpreted your recommendation.

And yes, there is no 100% protection against these kind of downloaders. 
However, we can give them a hard time and to use a staged folder can be 
a real help.

So, this is my opinion. :-)

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